Test Driven Development

This past week we worked on test drive development which was very difficult for me do to me being used to working with only source code first then writing test code. This new approach in my head was fairly easy, but when I went to code it, I was struggling. I believe part of this struggle was due to me not thoroughly writing out my test cases and taking the time to fully understand what I was doing. I ended up doing better on the testing for the homework than the activity I believe because I took a step back to understand and read more in depth into the five steps provided. I decided to also read more on another website (sourced down below) about test driven development, which this website went into more of the process of it and how the cycle works. It explored the history of it as well as the advantages and disadvantages.

These advantages included how writing the tests first provided constant feedback to the developer as well as always meeting the requirements more in depth and not having unnecessary tests or codes. This helps developers decrease production time in some scenarios due to only having to write the tests than source code to only specially pass that one test and if needed down the road to refractor code the developer can do so as well, but they will know what went wrong and reach their conclusions much quicker. The disadvantages spoken about are increased code volume which can be a pain currently or down the line when the code is going to be refactored or maintenance. Also, a huge disadvantage that can lead to multiple issues is false security from tests which some developers will go in and assume since one test passed, they do not need to make more. I believe personally for larger applications test driven development is not the best idea due to ever growing projects which will require lots of testing and can only be written after the source code to ensure they all work together rather than individually because some methods rely heavily on other methods.

The great thing about test driven development though that I learned and enjoy is finding bugs much earlier on. It helps me quickly go back and refractor my code for the test to pass but as stated previously it has its advantages and disadvantages. Overall, I had a hard time with it because I have never heard of it until now, but reading more about it I understand the main concepts of it. The activities in class did help discussing with the team as well as the homework, but the thing that confused me about the homework was the log since I usually don’t write logs on how and what test I am going to do because I base it on the source code. Overall, it was a great experience, and I am glad I was exposed to it so I can try it more on my free time and see how it is used in the real world.

Source: What is Test Driven Development (TDD)? | GeeksforGeeks

From the blog Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

Favor real dependencies for unit testing

URL: https://stackoverflow.blog/2022/01/03/favor-real-dependencies-for-unit-testing/

Mark Seeman brings us an interesting idea about which dependencies should be used during testing. In his article Favor real dependencies for unit testing, he explains that not every dependency necessarily helps you develop your tests. His main point concerns the use of dependencies that generate some kind of fake implementation of your methods in order to allow you to test them. One great example of this is Mockito, a widely used Java library where you can ask the tool to mock an entire class implementation. Although that sounds completely reasonable at first glance, what could be one issue that Mark is possibly missing in his argument? I would say that he is missing the reason why developers often rely on mocks and stubs in real-world development scenarios.

The main reason someone may choose to use mocks and stubs is more related to collaborative group work rather than projects handled by a single developer. In group settings, such as when working on a complex system like a hotel booking website, developers are usually assigned to different components or features of the system. For example, imagine a situation where you are working as a developer on such a project and are responsible for the Bookings class, while your teammate is assigned to the Suites class. Both of you have been making progress on your respective parts, and now you want to start writing tests to ensure everything functions as expected.

However, if any of your methods rely on a function that your teammate has not yet implemented, you could run into difficulties. Without the other function available, you might not be able to fully test your own code, even though your part is technically complete. This could lead to a development bottleneck, preventing you from moving forward until the rest of the system is ready.

To solve such a problem, one practical solution is to use libraries like Mockito. These tools allow you to create a mock version of your teammate’s class or method, enabling you to continue writing and running tests without delay. As explained earlier, Mockito generates fake implementations that simulate the behavior of the real components. This makes it possible to isolate and verify your own code independently.

Mark’s point is valid in scenarios where a developer is solely responsible for both the implementation and testing of all related methods. In such cases, using real dependencies like database fakes or stubs may be more effective. However, in collaborative environments, mocking libraries are essential tools that support parallel development.

This article surprised me with its perspective and application. As I’ve learned in class, the use of mocks allows developers to test features that haven’t been implemented yet adding a useful layer of abstraction. I believe that such libraries are not meant to stay in the codebase permanently but rather serve as temporary scaffolding—tools meant to be discarded once the full system is in place.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Top javaScript testing frameworks

Jest:

Developed by Facebook, Jest is one of the most beginner friendly frameworks, especially for those working with React. It comes pre-configured and includes a test runner, mocking, and assertion libraries. Its snapshot testing and excellent documentation make it a favorite among React developers. However, debugging can be tricky in some IDEs, and large snapshot files can be hard to maintain.

Mocha:

Mocha is a flexible framework ideal for Node.js applications. Its simplicity and long-standing presence in the testing world make it reliable. With support for async testing and various plugins like Chai and Sinon, it offers solid control. That said, it requires more configuration than Jest and lacks some built-in features.

Jasmine:
Jasmine supports asynchronous testing and integrates well with external libraries. It’s loved for its flexibility and extensive community support. The trade-off is more setup complexity, especially if you need additional libraries for mocking or assertions.

Nightwatch
Nightwatch is great for E2E testing with Selenium WebDriver. It’s particularly useful if your team has a Java background, thanks to its object-oriented syntax. However, its syntax can be less readable, and logging failures can be cumbersome without detailed error messages.

Playwright
A rising star from Microsoft, Playwright allows you to automate Chromium, Firefox, and WebKit using one API. It’s fast, supports modern web features, and works well with headless browsers. Being newer, it still lacks the depth of resources available for older frameworks.

Puppeteer
Built by Google, Puppeteer is tailored for Chrome/Chromium automation. It’s fast, developer-friendly, and ideal for tasks like form submission or page scraping. Its main limitation is the lack of cross-browser support.

Selenium
The veteran of test automation, Selenium remains the go-to for cross-browser testing. While powerful, it often requires additional setup and can struggle with scalability unless paired with tools like Selenium Grid or LambdaTest.

Karma
Karma offers real-time feedback and runs tests across devices and browsers. It supports popular frameworks like Mocha and Jasmine. It’s highly flexible, though less commonly used in newer projects today.

Cypress
Cypress is designed for modern JavaScript apps and offers unique features like time-travel debugging and real-time reloads. It runs directly in the browser but is limited to a few supported browsers and doesn’t allow multi-tab or remote execution.

Final Thoughts
Your ideal framework depends on your project’s size, tech stack, and testing goals. Whether you’re working with React, Node.js, or need robust cross-browser support, there’s a JavaScript testing framework tailored to your needs. Test smart, and happy coding!

Reference: https://www.lambdatest.com/blog/top-javascript-testing-frameworks/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

My task in Sprint 2 was to modify all endpoints to accept access tokens that will determine the system whether the request is from an authorized individual making that request. The goal is that these tokens will let the system know if the requester is authorized. But this can only happen after the IAM team figures out how the tokens will work. In this sprint, I collaborated very closely with my partner Sean Kirwin.

What was best for me in Sprint 2 was to work with Sean and continue to work on the backend. I was working on an issue that I am comfortable with again. I was also able to continue a task that was in progress from the previous sprint.

As a team, we still managed to get along. Communication from my teammates was really the best. Every individual could complain about what issues they were facing, why they were late to class or missing class, and was helpful whenever someone needed help from a teammate. Every week, my teammates were always there to offer helpful criticism, and I appreciated their help when I needed it. They also answered my questions about how to proceed with my assignment. I know that there is always room for improvement. However, I think that my team did very well in this sprint and we did not have any major issues during this sprint.

Relying on another team was somewhat challenging for me. We were not able to accomplish as much as needed because we were waiting to see how the tokens will be, as it is the IAM team’s decision to make that. Although we keep communicating with them on Discord, in my opinion, we should have sat down and spoken face-to-face or on Zoom so that we can better understand each other’s views. I sort of felt like both teams were getting a bit mixed up with each other’s arguments. The pattern I associated with from the Apprenticeship Patterns book was “Create Feedback Loops”. Here in this chapter, it highlights the importance of constant, actionable feedback in speeding up learning and improvement in the journey of an apprentice towards mastery. Feedback loops facilitate the discovery of weaknesses, confirm progress, and hone skills. They are imperative to move from apprentice to journeyman and later to master because they enable self-awareness and incremental improvement.

I chose this pattern because it is so closely related to what was happening in the sprint. Although it is stated not to move/work on tasks from the previous sprint, I managed to do so because I had the time available to complete a small mistake that was executed in sprint 1 in order to wait for feedback from the other group so that I could work on my task in sprint 2. I was able to learn the feedback from my other team members and rectify the small mistakes done during sprint 1. The “Create Feedback Loops” pattern helped me to step back, hear the feedback from my peers, and strategize on how to improve.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/141

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospect

In sprint 2 my team and I actually got the project functioning as we had intended. We now have a webpage with a scanner that can read UPC codes off any product we can find. A fetch script that takes that UPC code and uses an FDA API to give us data on the product. This data includes brand, brand owner, product category and a description. This data is then merged into our back end and stored with a quantity that gets manually entered. 

While demoing the webpage our customer seemed very interested in it and how user friendly we had made it. They seemed concerned about having to scan every individual product until they saw that you only needed to edit the quantities after scanning one single time. There is only one issue we have in that regard. We are not able to find absolutely any products data in that FDA API. However we are in the process of creating manual entries that will be saved, so it will only be a problem the first time that item is scanned. Attempting to keep our theme of user friendliness.

It has been cool and very rewarding for the team to actually see our project function this way. We’ve all done projects where things don’t really get to the point of looking and functioning like a completed product. This is a first for a few of us.

Our communication with each other during the weeks has stayed pretty consistent throughout this entire semester. I would say that is the strongest characteristic of this team. We all hold each other accountable by just being visible and seeing the others working hard to get this done.

Relating our team with a chapter from the book apprenticeship patterns, a good one would be – be the worst. With our strong communication and the fact we are putting the different parts of our project together into one product. We all noticed the strengths each member has to offer. All though this does not perfectly match the example of the book by surrounding yourself with a full team that is better than you. I think we have all done a good job at noticing each other’s strengths and understanding of each portion. This sprint showed how much we really started to learn and grow as a team. 

After sprint one I wanted to make it clearer for everyone to understand what each part of the team was doing and where they were at. This sprint actually managed to do a lot of this for me. While putting the pieces together everyone really started to see the full picture and there was points when you could see the excitement across everyone’s face when things started to shape up and start working. This also proved to create a more cohesive team as the pairs that had been working in a more broken off system were having to explain what they did in order to get certain parts to function properly. Now that everyone’s working in the same directories we all witness the fast pace of progress we have had the whole time, that I believe I was the only one really witnessing.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend

-this is the current state of our project. It has a working webpage, back end and fetch script that works between them.

Start up:

  • start the backend using bin/rebuild.sh
  • Install the live server extension on vscode
  • Right click scanner.html and open with webpage
  • Start scanning items =]

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospect Blog 2

If I were to put our journey so far in simpler terms, that gamers like myself would have an easier time understanding, I would say that this whole project has felt like an MMORPG game. During the first sprint, we all had nearly no idea what we were doing, trying to do easy tasks just so we could get a few levels and understand the mechanics behind the game so we could maybe get a glimpse of the bigger picture. After that was said and done, coming into the second sprint of this project, we all felt more comfortable with the project and its continuity. By now, we all have a clear image of our roles and what we bring to the table. We no longer run around aimlessly trying to defeat a minor boss, but now each of us has developed specific skills that make “fighting challenges” feel like a walk in the park, and everything goes smoothly like clockwork.

The one apprenticeship pattern that I would choose for this sprint would be “Concrete Skills – Making your abilities tangible and demonstrable”. We are entering into a more advanced phase in our journey as CS students, with most of us graduating in a month, so now is the time to let go of the abstract knowledge and hone tangible and demonstrable skills. This pattern really pushes you to refine your skills with specific and marketable abilities. The division into subgroups pushed us to learn more about particular skills. Working on the backend and connecting it to the frontend pushed me to learn or better yet, refine some skills that I thought I had a pretty good understanding of until I had to put them in practice. My teammates had already done a great job setting up the front end and adhering to visual identity guidelines, which meant I had to do as good of a job as they did, making everything functional and smooth.

After creating a functional backend last sprint, now I had to connect it to the frontend and make it actually “do something”.
I started by copying the front-end files my teammates had worked on so far to our main branch and started editing their scanner and database files. A simple JS script to fetch the information from the FDC database and add it to our own backend was all that it took to give life to our project. It took me a while to figure out the correct pathing for each API call, but once that was set up, everything was a breeze. My teammates had also created a “Database” page in which we would store our scanned products. I populated the page with items stored in our backend from the previous scanner page. After that, adding two buttons that were connected to simple API calls made the page more interactive. Now we can easily store, edit, and delete products, which is way more than what was asked of us initially.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/b57e1ea44a8113bac4075769da0b25336c975c8f – my latest commit with all the functionalities.

I guess if I had prior knowledge of the above-mentioned pattern, I would have had an easier time working on the project, as I would have “honed” my knowledge of backend-to-frontend connections beforehand, which would make my work even more efficient.

My teammates continue to be a great force in this project, and we are able to communicate clearly between us and solve issues in a short and manageable time without putting a lot of strain on ourselves. In fact, our communication might even backfire in a sense because we solve the issues so efficiently that we don’t even put them up on the issue board, a simple “hey, we have to fix this” is all that it takes to “clear” an issue, so we might want to work on that a little bit for the upcoming sprint.

Going back to my analogy, I guess that by now we have reached “level 40” with the cap being at 60. I hope that as we reach the “end-game,” we continue to have the great teamwork that we have had so far and that has helped us so much. We all have our roles and work cut out by now, so tackling this last sprint should be easy, with the end result being a successful project that we will leave behind but take with us valuable, tangible skills to help us take on future projects and challenges.

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.

Sprint 2 Retrospective Blog

During Sprint 2, my main task was to update our REST API by replacing the use of WSUIDs with UUIDs. Our sprint planning phase for this sprint was good, we broke down the tasks into what everyone would be doing for the sprint. Our communication was effective, especially during our team meetings in class. To implement the switch from WSUID to UUID, I updated the open API specification to reflect the new identifier structure. One of the key wins in this sprint was the successful refactor of the API to use UUIDs instead of WSUIDs for identifying guests. This transition improved the design by making guest identifiers more secure and consistent. I gained a deeper understanding of Open API specifications and how to maintain consistency across the schema definitions and endpoint parameters. Using UUIDs helped eliminate potential conflicts or collisions that may have occurred with custom WSUIDs. Collaboration also worked well with my team. Once I communicated the change to my teammates, everyone was supportive in reviewing related files and helping test the changes locally. This made integration and deployment less stressful.

At first, I underestimated how widespread the WSUID field was across the codebase. I initially thought I could change a few lines in the schema, but it quickly became clear that the change had to be made in multiple endpoints, error responses, and even test data. I had to backtrack several times to hunt down instances of WSUID that I missed earlier, which slowed down progress and created some confusion. Additionally, I didn’t write enough tests initially. As a result, one of the updates to the /guests/{uuid} path temporarily broke until I realized the mock data still used WSUID formatting. In the future, I need to write and run tests as I go rather than treating it as a final step. As a team, I think overall we have worked well and collaborate well with each other. Personally, I need to improve at assessing the scope of tasks more accurately. I underestimated the time and complexity involved in replacing WSUID to UUID. I want to become more consistent about writing tests early in the process.

“Be the Worst” from Apprenticeship Patterns (Chapter 2) encourages developers to seek out teams where they are the least experienced. The idea is that being surrounded by more skilled developers pushes you to grow faster through mentorship, observation, and collaboration. During this sprint, I didn’t have as good experience working with API design and backend architecture. At first, I felt a bit behind, especially when I didn’t account for all the areas affected by the WSUID-to-UUID switch. This pattern reminded me that growth often comes from being challenged by your environment and teammates. Had I internalized this pattern from the start, I would have asked more questions earlier instead of assuming I had to figure everything out solo. I would have scheduled a quick check-in to confirm I was on the right path before updating the spec. By embracing being “the worst,” I could’ve saved time and avoided some of the errors that slowed me down mid-sprint. This sprint taught me that meaningful growth comes from deep work, reflection, and surrounding myself with teammates who challenge and support me. I look forward to carrying these lessons and complete sprint 3 successfully.

References.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/142

From the blog CS@Worcester – Lynn'sBlogs by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

CS-443: Blog 4

 CS@Worcester CS-443

For this post, I reviewed “Why is quality assurance a key to software development success?” by Emily Dobutović

  The article explains how quality assurance (QA) is a fundamental aspect of software development, ensuring that products meet both business and technical requirements while maintaining high standards of reliability. It emphasizes that QA is not just about detecting bugs but involves a structured process spanning multiple phases, including requirement analysis, test planning, development, execution, and maintenance. QA engineers play a crucial role in improving quality control and testing, helping companies reduce post-launch defects and enhance user satisfaction. The article also highlights the importance of automated testing, which accelerates delivery and minimizes manual errors, making software development more efficient.

Additionally, the article explores various testing methodologies and tools that contribute to successful QA implementation. It discusses how integrating QA early in the development cycle prevents costly errors and ensures a smoother user experience. The structured approach to QA, including defining test strategies, environments, and automation techniques, helps organizations maintain software integrity and reliability. By prioritizing QA, businesses can achieve higher customer retention and reduce long-term maintenance costs. 

I think this was a pretty interesting article. I found that it was well put together, and that it goes in detail about quality assurance. What made sense to me is how quality assurance is essential for maintaining high standards in software development, manufacturing, and various industries. It could help with Defect Prevention, Risk Management, Process Improvement, and Compliance & Standards.

From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.

CS-443: Blog 4

 CS@Worcester CS-443

For this post, I reviewed “Why is quality assurance a key to software development success?” by Emily Dobutović

  The article explains how quality assurance (QA) is a fundamental aspect of software development, ensuring that products meet both business and technical requirements while maintaining high standards of reliability. It emphasizes that QA is not just about detecting bugs but involves a structured process spanning multiple phases, including requirement analysis, test planning, development, execution, and maintenance. QA engineers play a crucial role in improving quality control and testing, helping companies reduce post-launch defects and enhance user satisfaction. The article also highlights the importance of automated testing, which accelerates delivery and minimizes manual errors, making software development more efficient.

Additionally, the article explores various testing methodologies and tools that contribute to successful QA implementation. It discusses how integrating QA early in the development cycle prevents costly errors and ensures a smoother user experience. The structured approach to QA, including defining test strategies, environments, and automation techniques, helps organizations maintain software integrity and reliability. By prioritizing QA, businesses can achieve higher customer retention and reduce long-term maintenance costs. 

I think this was a pretty interesting article. I found that it was well put together, and that it goes in detail about quality assurance. What made sense to me is how quality assurance is essential for maintaining high standards in software development, manufacturing, and various industries. It could help with Defect Prevention, Risk Management, Process Improvement, and Compliance & Standards.

From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.

CS-443: Blog 4

 CS@Worcester CS-443

For this post, I reviewed “Why is quality assurance a key to software development success?” by Emily Dobutović

  The article explains how quality assurance (QA) is a fundamental aspect of software development, ensuring that products meet both business and technical requirements while maintaining high standards of reliability. It emphasizes that QA is not just about detecting bugs but involves a structured process spanning multiple phases, including requirement analysis, test planning, development, execution, and maintenance. QA engineers play a crucial role in improving quality control and testing, helping companies reduce post-launch defects and enhance user satisfaction. The article also highlights the importance of automated testing, which accelerates delivery and minimizes manual errors, making software development more efficient.

Additionally, the article explores various testing methodologies and tools that contribute to successful QA implementation. It discusses how integrating QA early in the development cycle prevents costly errors and ensures a smoother user experience. The structured approach to QA, including defining test strategies, environments, and automation techniques, helps organizations maintain software integrity and reliability. By prioritizing QA, businesses can achieve higher customer retention and reduce long-term maintenance costs. 

I think this was a pretty interesting article. I found that it was well put together, and that it goes in detail about quality assurance. What made sense to me is how quality assurance is essential for maintaining high standards in software development, manufacturing, and various industries. It could help with Defect Prevention, Risk Management, Process Improvement, and Compliance & Standards.

From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.