Monthly Archives: March 2024

Mastering Advanced Unit Testing: Test Doubles and Code Coverage for Beginners

As developers, writing robust, reliable code is a top priority. And when it comes to ensuring the quality of our codebase, unit testing plays a pivotal role. However, as we delve deeper into the realm of unit testing, we encounter advanced concepts like test doubles and code coverage, which might seem intimidating at first glance. But fear not, for in this beginner’s guide, we’ll demystify these concepts and explore why they are essential for writing high-quality code.

Understanding Test Doubles

Test doubles, also known as mocks, stubs, or fakes, are objects used in place of real dependencies in unit tests. They simulate the behavior of these dependencies, allowing us to isolate the code under test and verify its interactions with its collaborators.

For instance, imagine you’re testing a class that relies on an external API. Instead of making actual API calls, you can use a test double to mimic the API’s responses, ensuring your tests run swiftly and independently of external factors.

Test doubles help in:

  1. Isolation: By replacing real dependencies with test doubles, we can focus solely on testing the behavior of the unit under scrutiny without worrying about the intricacies of its collaborators.
  2. Speed: Since test doubles operate in-memory and don’t involve external resources, tests run faster, contributing to quicker feedback loops during development.
  3. Determinism: Test doubles allow us to create predictable test scenarios, ensuring consistent and reliable test results across different environments.

Code Coverage

Code coverage measures the proportion of a codebase that is exercised by automated tests. It provides insights into areas of code that lack sufficient test coverage, enabling developers to identify potential bugs and improve overall code quality.

While achieving 100% code coverage doesn’t guarantee bug-free software, it serves as a valuable metric for assessing the thoroughness of our test suite.

Code coverage aids in:

  1. Identifying Untested Code: It highlights parts of the codebase that lack test coverage, prompting developers to write additional tests for those areas, thus reducing the likelihood of undetected bugs.
  2. Improving Confidence: Higher code coverage instills confidence in the codebase, indicating that most critical paths and edge cases are adequately tested, thereby reducing the risk of regressions.
  3. Refactoring Safely: With comprehensive test coverage, developers can refactor code with confidence, knowing that any unintended changes are likely to be caught by existing tests.

In conclusion, mastering advanced unit testing techniques like test doubles and code coverage is crucial for any developer striving to deliver high-quality software. By leveraging test doubles, we can isolate units under test, while code coverage empowers us to assess the thoroughness of our test suite. Incorporating these practices into our development workflow not only enhances code quality but also fosters a culture of test-driven development, ultimately leading to more robust and maintainable software.

For further reading, check out this article from Christian Findlay on writing testable code and its importance in software development. Happy testing!

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Path Testing Demystified

Hello, It’s me, your favorite computer science student ready to once again complain about the career path I chose myself.

Today’s menu of minor headaches (I’ve got to stop using this) consists of Path Testing, which is the same as checking every corner of your room for monsters before going to bed to ensure your beauty sleep doesn’t get interrupted.

Imagine you’re playing a video game where you choose paths to reach the exit of a maze. Some paths are straightforward, others are mazes with obstacles. Path testing is the same principle but with your code. You need to check every route your code can take to catch bugs hidden off the beaten path.

Think of your code as a map, with each part representing a stop or a crossroad. The goal is to explore all the stops and paths without an endless journey. We use a Control Flow Graph as a map for your code to ensure that we are not missing any hidden detours.

To implement Path Testing you only need to follow a few key steps:

  1. Create the Control Flow Graphs: This graph maps out all the possible routes through the program.
  2. Calculate Cyclomatic Complexity: This metric is the guide for the number of test cases needed for adequate coverage.
  3. Identify Independent Paths: Determine the set of paths that cover all the edges and nodes in the graph.
  4. Design Test Cases: Create test cases that will traverse each identified path.

That’s pretty much it.

Now you may say “But Ano why even bother with Path testing?”. Well, Path Testing is your code’s ultimate test drive. It uncovers sneaky bugs that hide in specific conditions and gives you a deep understanding of your code, making it easier to add features without issues.

And yet there is a catch. While Path Testing may be great, it can also be tricky for complex apps. Trying to test every path can feel like planning a road trip to Mars. The key is to smartly select which paths to test, covering as much ground as possible without getting lost in the details.

Just like our previous entry on software testing, Path Testing is another secret weapon for robust code. It’s meant to bring you peace of mind, ensuring your app or program performs without any flaws. So, before you deliver or push your code, be sure to take it on this essential road trip that guarantees your code does what it is supposed to.

Till next time,

Ano out.

References:

https://www.geeksforgeeks.org/path-testing-in-software-engineering

https://www.guru99.com/basis-path-testing.html

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

‘Find Your Mentors’ Pattern

The ‘Find Your Mentors’ pattern is about the idea of “apprenticing” yourself to someone who is more experienced than you are within your field of expertise. While this pattern should be considered for many different professions it should especially be considered for software development as having a mentor can be very helpful especially when you are trying to find your place in the huge world of software. One of the main ideas attached to this pattern is that you will have the realization that you are not the first person to start out being a software developer with little experience professionally as everyone that is currently in the field had to start at the same spot you are currently at and their knowledge can be beneficial to you in order to shape your own career and practices. The solution provided for this pattern is finding a master craftsmen in order to be supervised by them and have the proposed master shape your understanding of the field and your career, but it is also said that with computer science being a relatively ‘young’ field it is hard to find a true master as their are not many people that have ‘mastered’ all of computer science but that there are many people who may have mastered parts of computer science and you should seek out different people in order to increase your understanding of what each mentor you obtain has mastered in their time in the field.

I feel as though this pattern is very important because computer science is younger than many other fields and mentors can be hard to come by in fields which have many ‘masters’ nevermind fields which have very few like computer science. Explaining that it is ok and completely acceptable for a software developer to have many mentors throughout their professional journey in the different disciplines of computer science helps students such as myself realize that you can continue to explore further and further into the field without having to necessarily pick a specific discipline and settle to work on only that discipline for our entire careers but instead that we should feel encouraged to gain more knowledge as knowledge on other disciplines can help us to gain understanding within whichever discipline we are currently working within.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Black Box Testing

https://www.practitest.com/resource-center/article/black-box-vs-white-box-testing/#:~:text=The%20Black%20Box%20Test%20is,is%20carried%20out%20by%20tester.

Black box testing is a genre of testing which does not take a codes functionality into consideration, in other words the internal workings of the code are not known to the test and the tests are formed strictly by external workings. This is very different from white box testing as white box testing operates under the idea that the ‘tester’ has extensive knowledge of how a system was created along with its inner workings. Some of the differences between black and white box testing are black box testing is carried out by ‘tester’ while white box testing is left to software developers, black box testing is considered behavior testing while white box testing is considered logic testing and black box testing is typically used in system testing while white box testing is used in unit testing. There are also ways in which these two types of testing are similar which is mainly their purpose which is to ensure that a system is working correctly and that you have the best version of the software available.

I chose this article because I liked how it not only explained black box testing but it also compares black box testing to white box testing in order to allow a deeper understanding of the relationship between the two types of testing. I am very interested in seeing how different methods of black box testing work as for the most part we have been practicing with white box testing methods in class so far this semester so the concept of testing without extensive knowledge of a system or without access to the systems internal workings and code seems both interesting and challenging to me. 

With there being a large gap in knowledge of a system between the two different types of testing it seems as though black box testing is something that is done by others not necessarily full blown software developers as developers are expected to spend their time on white box testing so It makes me wonder how exactly these tests are written and how specific results may be measured for success compared to the more straightforward nature of white box testing. Since black box testing can be used for just about every type of testing, even some of the sames types of testing white box is used for it would be nice to see and compare how tests are carried out for both types of testing on a similar component of a system in order to differentiate the information used by each type.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

The Logic of Software Testing

Hello everyone,

Although we have been studying software testing for a few weeks, I still want to talk about the “logic” of software testing. Because I think it’s important, to test software comprehensively, we must understand the “logic” of testing. So I want to share a blog with you today:

“What is the Underlying Logic of the Software Testing? ”

by ZenTao 3

Link: https://www.zentao.pm/blog/underlying-logic-of-the-software-testing-1-1249.html

As a student new to software testing, I find the topic of test logic particularly interesting. Recognizing its critical role in ensuring software reliability and functionality, I sought out some resources that could help me develop an understanding of the underlying logic behind the testing process. This blog post does a great job of explaining this to me, providing insight into the complex mechanisms that support effective software testing.

In the first chapter of the article, we learned about the basic requirements for software testing:

  • Software testing is to verify whether the functional characteristics of software meet the requirements;
  • Software testing is to find the defects in the software;
  • Software testing includes static testing – requirement, design, and code review
  • Software testing is to systematically and completely evaluate the quality of software products and provide quality information;
  • Software testing is to expose and reveal product quality risks;
  • Software testing is not only a technical activity but also a comprehensive social and psychological activity;
  • Software testing is to greatly reduce the cost of poor quality by investing in quality assurance costs.

These guidelines will play an important role in our future software testing path. All our testing will be conducted based on these guidelines. Also, article mentioned “based on the understanding of the real needs of users, to obtain the true and comprehensive quality information of software products through various means.” If we become professional software testers in the future, during the testing process, we must Always ask yourself if you are being comprehensive.

What impressed me most was the second chapter in the blog: The Underlying Logic of the Software Testing. And its three questions:

  • Why？
  • What？
  • How？

Why: Because humans are not machines, even machines can make mistakes, so human work will inevitably lead to errors and imperfections due to some reasons (personal habits, time, abilities, etc.).

What: Be clear about the goals, scope, and specific data of the test. Prioritize your testing and do not do tests that are not relevant to your goals.

How: Sometimes obtaining existing test data will help us speed up and improve the efficiency of testing.

Overall, this blog is a great foundation for software testing. During our testing process, we need to ask ourselves whether the above problems have been solved.

From the blog CS@Worcester – Ty-Blog by Tianyuan Wang and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective Blog

Upon completing our first sprint and gathering for our retrospective meeting, it’s essential to reflect on what went well and identify areas where we can improve moving forward. Here’s a breakdown of our observations:

Reflection on what worked well:

  • We successfully completed most of the small issues, achieving a completion rate of around 75%, which demonstrates our ability to tackle tasks effectively.
  • Our meetings, though limited in frequency, were productive and provided valuable opportunities for discussion and collaboration.
  • The quality of communication within the team was commendable, fostering a supportive and transparent environment for sharing progress and addressing challenges.

Reflection on what didn’t work well:

  • We encountered challenges with Docker-compose issues and documentation, which impacted our ability to complete tasks efficiently.
  • Despite aiming for a total weight of 20, we only managed to achieve 15, indicating a discrepancy between the assigned weights and the actual difficulty of the tasks.
  • Details for issues were not easily accessible, as they were only located within the epics, leading to confusion and inefficiency.
  • Issue distribution was uneven, with some team members shouldering heavier workloads than others.
  • All GitLab logistics were handled by one person, potentially causing bottlenecks and hindering collaboration.
  • Individuals tended to work on issues independently, lacking assistance or support from other group members.

What changes could be made to improve as a team:

Better teamwork should be our top priority if we want to grow as a group. To do this, we should encourage teammates to help one another out when necessary and promote cooperation and knowledge exchange. Furthermore, by more precisely allocating weights in light of the lessons we learned from the previous sprint, we can guarantee that activities are appropriately scoped and assigned, averting disparities in workload allocation. Cooperation and efficiency will be enhanced by improving our knowledge of using GitLab and proactively supporting team members when necessary. Furthermore, it can facilitate communication and task execution to make issue details directly accessible from the issue itself, as opposed to only from the epic. Lastly, delegating tasks to one another instead of having one person do them all helps spread responsibilities fairly and encourage a sense of ownership among team members.

Works that I was assigned for and what changes could be made to improve as an individual:
During the previous sprint, I tackled two tasks within the ReportingBackend and ReportingIntegration projects for our LibreFoodPantry endeavor. For the first task, I was assigned with renaming the “commands” folder to “bin” (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/19) for both Reporting Backend and Reporting Integration. This involved not only simply renaming the folder but also ensuring that any references to “commands” within the codebase were updated to “bin” to maintain consistency. Although I successfully made the necessary changes to the scripts paths and ensured the projects ran smoothly, I overlooked updating all related documentation, which remained referencing the old paths.

For the second issue, I took on the challenge of integrating the AlexJS linter into the ReportingIntegration project’s pipelines (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/16). While initially encountering difficulties due to missing scripts, I leveraged external resources provided by our professor to overcome these obstacles. However, my decision to ignore certain files in the AlexJS test led to later feedback about refining this approach.

Moving forward, I recognize the importance of meticulous attention to detail and thoroughness in my work to avoid similar oversights and prioritize spending ample time on each task.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Walking The Long Road To Mastery

In our modern world, the journey to mastery is often overlooked in the software development field. Traditional notions of career advancement can cloud our vision as aspiring programmers, leading us away from the path of true craftsmanship. The Long Road pattern is a reflection on our journey of becoming masters in the field and emphasizes the importance of lifelong learning and growth. 

Reflecting on The Long Road pattern, I found myself in agreement with its core message, while also grappling with the implications it holds for my own career path. The pattern’s emphasis on mastery as a lifelong journey stood out to me, serving as a reminder of the importance of patience and persistence in the pursuit of excellence and success. 

The pattern also presents an analogy to martial artists attempting to receive the black belt and connecting it to software development. This highlighted the discipline, patience, and perseverance required to master any craft. Additionally, we should embrace our path, rather than just fixating on the destination. This reminded me that we should appreciate the process of learning and growth, rather than being solely focused on achieving immediate success. 

The Long Road has challenged me to essentially reassess my approach in the field. Instead of chasing after quick promotions or higher paying positions, I now see value in prioritizing long-term growth and development, and measuring progress based on understanding and my quality of work. Therefore, encouraging me to adopt a more patient and deliberate approach to my career, knowing that mastery is a process that’ll unfold over time. 

While I agree with the message expressed in the pattern, I couldn’t help but wrestle its implications with our rapidly changing industry. Today, new languages, methodologies, and frameworks evolve and emerge by the daily. The notion of dedicating a lifetime to master a single craft could seem unreasonable. While I value the importance of patience in honing my skills, I believe there is merit in adaptability and versatility. As developers, we must remain agile and responsive to change, continuously evolving our skill set to meet the demands of the evolving industry. Therefore, while I understand the message, I believe it’s equally important to embrace flexibility in our journey. 

This pattern has left a mark on my perspective as an aspiring craftsman. It has challenged me to embrace this journey of mastery with patience and perseverance, even when faced with uncertainty. As I continue to grow and walk down this path, I am committed to the principles of lifelong learning and growth, knowing that eventually reaching true mastery is a destination worth striving for. 

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

What Worked Well And What Didn’t:
After completing our first sprint and conducting our retrospective meeting, I would say that sprint #1 went really well. As a group, we were given three weeks to complete a total of thirteen different tasks for a total weight of 25, and only fell short of one for a total weight of 20 out of 25. What worked well with the team was that we all knew each other, allowing us to be comfortable with asking different questions or for assistance. Additionally, we were able to schedule weekly meetings whether virtually through Discord or in person. These meetings allowed everyone to be informed about project progress, issues, and next steps. Communication was a major successor for this sprint, further accelerating our knowledge within the project. For what didn’t work well, our timing of working on the project was slightly off. We gradually contributed but didn’t get the ball moving until the end of our sprint. I could understand this as some of us were unfamiliar with the functionality of GitLab and GitPod, and what was completed in the project. For the next sprint, working on the project little by little right when we start and understanding what we are dealing with, will provide us time to discover issues, figure out how to handle them, and complete our tasks in a timely fashion. Additionally, we should consider having a better review process to ensure everyone gets to review work.

Improvements As A Team:
To improve as a team, it would be great to further improve our communication. On days that we don’t have scheduled meetings, possibly posting an update on what everyone is currently completing, any problems they have, if someone needs something reviewed, and if they need help from another person on the team that may have knowledge on what they are working on could be beneficial. Also I believe we should begin working on our issues from the start rather than stressing and cramming everything all at once at the end of the sprint. We should also implement a better reviewing process.

Improvements As An Individual:
As someone who had just stepped into the project, I was unfamiliar with navigating through GitLab to find different things, what was completed within the project, and what needs to be worked on. After researching different things and searching through various repositories, I was able to figure this out. I was able to complete three issues individually and one issue as a group particularly working within the InventorySystem of the Theas Pantry project. My first issue was GitPod Dev Environment in InventorySystem/General. This involved having the Theas Pantry project work with VSCode in GitPod, rather than devcontainers. The second issue I completed was also GitPod Dev Environment in InventorySystem/InventoryAPI. I completed the same work to have VSCode work in GitPod rather than in devcontainers. My third issue was Move From ‘commands’ to ‘bin’ in InventorySystem/InventoryBackend. This issue involved changing the file name from commands to bin, updating all script paths to use bin, and ensuring pipeline stages like build, test, and release all functioned properly. I ran into an issue with the test pipeline for this specific task as files were missing. To correct this, I had to disable the test pipeline and plan on fixing this in the next sprint. The last issue I worked on was with my group, GitPod Dev Environment in InventorySystem/Documentation. We completed the same work to have VSCode work in GitPod rather than in devcontainers. To improve as an individual in future sprints, I would like to complete a little bit of work each day, rather than trying to just complete as much as I possibly can all at once. I spent a lot of time working on my issues and when something didn’t work, I’d burn myself out trying to figure out what the problem was. In future sprints, completing issues piece by piece can allow me to have a fresh mindset each time I work on the project and complete tasks in a faster, more efficient manner. Additionally, by completing a little bit each day, it can take away stress from time constraints and allow me to ask questions, get reviews, make changes, and improve the quality of my work.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

CS-448 Sprint 1 Retrospective

Merge branch ‘jlee1999/vscode-issue’ into ‘main’ (4ca23d2d) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

One of the problems I ran into came when combining issues within the same branch. For instance, within this one merge request to ReportingSystem General, there were three issues that were worked on which ruined the commit messages when squashing the branch. The commit messages would only reflect one of the issues being fixed rather than three separate commit messages that are associated with a particular issue.

Merge branch ‘jlee1999/gitpod-setup’ into ‘main’ (c2ec7bc6) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

This issue was in ReportingSystem Documentation and the task was to change the folder “commands” to “bin” to avoid any syntax errors within the code. This also required the refactoring of the code/files wherever “commands” was located so that it was changed to “bin”.

Merge branch ‘alexjs_linter_add’ into ‘main’ (6f9c803f) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / ReportingBackend · GitLab

This issue was in ReportingBackend and asked to add AlexJS linters to the pipelines. This required enabling the AlexJS test in gitlab-ci.yaml file so that the test would run through the pipelines when committing any changes.

Merge branch ‘jlee1999/alexjs-linter’ into ‘main’ (443debe1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

This issue was also related to adding AlexJS linters to the pipeline of GenerateWCFBReportFrontend to check the indicated files for any problems.

Merge branch ‘jlee1999/gitpod_setup_branch’ into ‘main’ (636896d3) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryIntegration · GitLab

This issue revolved around adapting InventoryIntegration to allow VSCode to work in Gitpod. There were some complications with this issue since this was the first issue I worked on and not all the pipeline tests passed when committing the changes.

For the first Sprint I think that there were a few things that went well during the process. I made sure that I would not get stuck on one issue for a long period of time so that way it did not hinder our overall progress through the other issues we needed to work on. A lot of the issues we were assigned revolved around the same thing, which made it easier to fix once solving the first issue in a repository. For example, setting up AlexJS linters to pipelines was required for us in multiple repositories in Thea’s Pantry, so once we figured out how to solve the first issue it was easy to carry over the same solutions to the other required repositories. The more I started working in GitLab and Gitpod/VSCode, the more comfortable I got with the layouts. This will continue to help through later issues and sprints as there is still more I can learn which will make it easier to fix different issues.

While there were positives to take away from my first experience in a Sprint setting, there were some things that did not work as well that hindered the overall progression of the project. At first, I forgot to create a separate branch when working on my first issue but then realized after committing the changes to the main branch. Luckily it was nothing too major that I was changing so it did not affect the entire repository. I personally would get caught up in too many issues at once and bounce around through multiple at a time.

I think the main thing that the team can improve on for the next sprint is more communication amongst everyone. The more communication there is, the easier it will be to identify what each team member is working on at the time. Letting each other know when there is a merge request to be reviewed will make it quicker to get through each issue and identify any mistakes that might arise in merge requests. As an individual, I can improve my focus on one issue at a time rather than working on multiple issues at once.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.