Category Archives: CS-443

New Perspectives: Chris James’ TDD Thinking Hats

In our Software Quality Assurance and Testing course, we have been learning about Test-Driven Development (TDD) and how it supports building stable, maintainable software. Chris James’ blog post, “The TDD Thinking Hats,” connects directly to our coursework by offering a helpful way to think about the different stages of test-driven development. Instead of just following steps, James introduces the idea of “thinking hats” to better focus on what kind of mindset is needed at each point in the process. James also acknowledges the concept he is applying to test-driven development in this post stems from the “Six Thinking Hats” which is a broader idea that is from an Dr. Edward de Bono book.

James outlines three main hats:

  • The Green Hat is worn when writing a new test, emphasizing thinking like a user and focusing on desired behavior.
  • The Red Hat is worn when tests are failing, where the priority is to quickly fix the issue without making too many changes outside of the direct problem.
  • The Blue Hat is for the refactoring stage, when the tests are passing, allowing the developer to enhance the code

I chose this blog post because while test-driven development has been introduced in our coursework, I have sometimes found it difficult to manage the different phases clearly when applied. It is easy to get ahead of yourself — trying to refactor before a test passes, or worrying too much about details when writing a test. This concept helps me see how keeping a more distinct mindset at each step can prevent mistakes.

A point of interest for me was James noting that feeling uncomfortable during the Red stage is normal and even expected. In the past, when facing failing tests, I would often get discouraged or rush to fix the code without even thinking. Now I see that treating the Red stage as a signal to slow down and focus on getting back to green is a better approach. I also learned the importance of avoiding large changes while tests are failing, something I will pay closer attention to moving forward. Small incremental steps seems to be the recurring idea behind test-driven development

As I continue to learn, I plan to consciously apply this “thinking hats” approach when practicing test-driven development. I will aim to be more intentional: practical when writing tests, focused when resolving failures, and careful when refactoring. I expect that doing so will not only help me better follow the test driven development cycle, but also improve the quality and structure of my code overall. This blog post gave me a new practical framework to apply what we have been learning about test-driven development. It made the process feel more organized and achievable, which I believe will help me develop stronger habits for quality-focused software development.

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

A Student’s Perspective on Technical Reviews in Software Quality Assurance

As a computer science student delving into the world of software development, I’ve come to appreciate the significance of various practices that ensure the delivery of high-quality software. One such practice that recently caught my attention is the concept of technical reviews in software quality assurance.​

I explored the article “What is Technical Review in Software Testing?” by Testsigma, which provided a comprehensive overview of this critical process. A technical review is a structured evaluation conducted by a team of peers to assess the technical aspects of software artifacts, such as design documents, code, and test plans. The primary goal is to identify defects and areas for improvement early in the development lifecycle, thereby reducing the cost and effort associated with fixing issues later on.​

The article outlines several key objectives of technical reviews:​

  • Defect Detection: Identifying errors in function, logic, or implementation before they propagate further into the development process
  • Standards Compliance: Ensuring that the software adheres to organizational and industry standards.​
  • Knowledge Sharing: Facilitating the exchange of ideas and knowledge among team members, which can lead to better design decisions and coding practices.​
  • Process Improvement: Providing feedback that can be used to refine development processes and prevent future issues.​

Reflecting on this, I realize that incorporating technical reviews into our academic projects could be highly beneficial. Often, we focus on completing assignments and meeting deadlines, sometimes overlooking the importance of peer evaluations. By implementing structured reviews, we can catch mistakes early, learn from each other’s perspectives, and produce more robust and reliable code.​

Moreover, understanding the practice of technical reviews prepares us for industry expectations, where such evaluations are integral to the development process. It emphasizes the collaborative nature of software engineering and the collective responsibility of a team to ensure quality.​

In conclusion, technical reviews are a vital component of software quality assurance, offering numerous benefits that extend beyond mere defect detection. As students aspiring to become proficient software engineers, embracing this practice can enhance our learning experience and better equip us for professional challenges ahead.​

For a more in-depth understanding, I recommend reading the full article: What is Technical Review in Software Testing?

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Understanding Mocks and Stubs in Testing

In software development, testing is key to making sure applications work the way they are supposed to. The blog post “Software Testing: Mocks and Stub” by Nicholas Lexi talks about two major tools in testing: mocks and stubs. This connects closely to what we have been learning in class about unit testing and keeping tests focused.

Summary of the Blog Post

The post starts by explaining why test isolation matters. When testing a piece of code, you want to make sure you are only testing that piece, not its outside dependencies. This keeps tests more reliable and easier to understand when they fail.

To help with isolation, the blog introduces mocks and stubs.

Mocks are fake versions of real objects that let you check if your code interacts with something the right way. You can use mocks to see if a method was called, or if it was called with the right information.

Stubs are simpler. They just return fixed responses when called. Stubs are useful when you want a test to run without relying on a real database, server, or other complicated system.

The post gives short examples showing how both mocks and stubs can be used.

Why I Picked This

I picked this post because we have been working with unit testing in class, and I wanted to better understand how mocks and stubs fit into writing cleaner tests. I had heard about them before but did not really get how they were different. Since isolation is so important in testing, I thought it made sense to dive deeper now.

Thoughts and Takeaways

One thing that stood out is how mocks and stubs have different goals. Mocks check behavior and stubs control data. That makes it easier to decide which one to use depending on what the test is trying to do.

Another big takeaway is how test isolation is about more than just making tests pass. It is about writing tests that fail for the right reasons, which makes fixing problems a lot easier.

Applying Mocks and Stubs

Going forward, I want to use mocks and stubs more when I am testing. Especially for anything that depends on APIs or databases, they will help keep my tests clean and focused. Practicing this now will help a lot when projects get bigger.

Conclusion

This blog gave me a better understanding of mocks, stubs, and why test isolation matters. Using them the right way will definitely help me write better, more reliable code.

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

CS443: Considering the Wheel (with Kent C. Dodd and Iain M. Banks)

O you who turn the wheel and look to windward,
Consider Phlebas, who was once handsome and tall as you.
– T.S. Eliot, The Waste Land (1922)

Certainly, no one is asking you to reinvent the wheel. At the same time, you shouldn’t take its existence for granted.

Industry veteran and offshoot CS educator Kent C. Dodds says as much here, in this short speech he gave in 2018 a system he called “Testing from the Wheel”.

Dodds describes the following strategy for testing code: Test a lot, test always, test from the bottom-up (starting with unit testing and finishing with high-level UI testing), and never forget to test.

From the accompanying blogpost Dodds wrote to expound on this system. Here he’s written over Martin Fowler’s famous Test Pyramid with strata of his own making: unit testing, integration testing, and finally, end-to-end testing, from least expensive to implement (and therefore best to undertake) to most.

Consider this. The wheel may have already been invented, but can you trust it without playing around with it yourself?

I’ll only test code which I know isn’t up-to-snuff. Anything else isn’t worth my time.

Consider this: as Dodd points out, oftentimes the lens by which we regard our tests with is forced to change, along with our understanding of the product as yet written. Whether by an honest error in the specifications or new priorities on behalf of the intended recipient, code changes fast. It makes sense, then, that our ability to pivot to those changes needs to be just as adaptive and reactive.

Kent C. Dodds at Fluent 2016.

When we consider the wheel, whether as part of a bottom-up test strategy as Dodd suggests or in our own deliberations, we should never forget the lesson it teaches us. As engineers, we must foster a sense of perennial inquiry which leads us to reexamine the most innocuous things in life. As developers, we must deliver product that is not only technically sound but financially so as well, which means expediting our review and test processes to a maximum. Every wheel, every time, everywhere.

Consider this: the vehicle that propels us all throughout life uses many wheels. And so many such wheels are taken for granted.

But if not the wheel, then what about Phlebas? Consider Phlebas.

The 2nd edition cover to Consider Phlebas. And, no, that’s not something you’d see a phlebotomist for.

Iain M. Banks’ silent, yet impassionate plea for his readers to understand hubris and its lingering aftereffects—not only on the soul, but on the character and legacy of a person—should ring especially clear and true with programmers of all walks. Sometimes we create something bold and are enamored by our own work, when really we should be questioning ourselves for our own good.

Surely this code is already really good. I don’t think I need to test it.

Like Pygmalion, we can ofttimes delude ourselves into thinking our code is so well-written that it needs no review. But in doing so, we endanger the stability of our own codebase and any future additions. Always test. Always, every time, everywhere.

Like the wanderer traveling through the senseless, meandering Waste Land of Eliot’s embattled imagination. Like Banks’ non-eponymous stand-in for Phlebas himself, though “he be a thousand years in his grave.” The lesson of self-agency is not one of jubilation, but rather a cautionary tale of despair. Because the people who possess it are destined to become their own undoing. Like us, if we don’t learn to know any better. If we don’t strive to challenge and doubt ourselves. If we don’t stop to consider the wheel.

Whether the most junior DevOps specialist or the most senior CTO, consider the wheel, simple and true, and sometimes deserving of your full consideration in spite of that.

Sometimes, it’s better to understand how to come back from success than dealing with having too much of it.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Why Test-Driven Development Is More Useful Than I Thought

In software development, strong design habits are key to building software that is easy to understand and change. The blog post “Test-Driven Development: The Best Thing That Has Happened to Software Design” from Thoughtworks talks about how Test-Driven Development, or TDD, improves both code quality and design. This connects directly to what we have been learning in class about writing better, more reliable code.

Summary of the Blog Post

The post explains that TDD is not just about writing tests before coding. It is a way of working that leads to cleaner, better-organized software.

Writing tests first forces developers to think about what they want the code to do. It also leads to smaller, more focused units of code that are easier to test and maintain.

TDD also encourages better object-oriented design. Since you are planning behavior early, classes and methods tend to have clearer responsibilities. Another major point is that TDD makes refactoring safer, since a full set of tests can quickly catch mistakes.

Even though TDD can feel slower at first, the blog points out that it saves time in the long run by reducing bugs and making changes easier.

Why I Picked This

I picked this blog post because we have been learning about TDD in class, and I wanted to understand why it is considered such a big deal. Before reading this, I thought TDD was just extra work. This post showed me that it is really about designing better code from the start. Since TDD is common in real-world development, it made sense to learn more about it now.

Thoughts and Takeaways

One thing that stood out to me is how TDD helps you spot design problems early. If your code is hard to test, that is usually a sign it needs to be simpler. I had not thought about testing as a way to catch bad design, but now it makes perfect sense.

Another takeaway was how TDD makes refactoring less scary. In the past, I was nervous to change code that already worked because I was afraid of breaking it. With a strong set of tests, making improvements feels a lot safer.

Applying TDD

I want to start practicing TDD more, even on smaller projects. It might take some extra effort at first, but if it helps me write better, more flexible code, it is definitely worth it. Getting into good habits now will only help me later on bigger assignments and real-world work.

Conclusion

This blog post gave me a much better understanding of why TDD matters. It is not just about finding bugs, it is about building software that is better from the start. I am definitely motivated to practice TDD more and make it part of how I approach coding.

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

Overview of combinatorial testing

In complex programs, choosing valid test cases often means choosing from many different possible combinations of inputs to find the correct cases. Doing this could take an unnecessarily long time, slowing down the development process, and possibly causing some important cases can be missed. In the article, “Combinatorial testing: What is it, how to perform, and tools”, author Shanika Wickramasinghe explains the details of combinatorial testing, and how it solves the aforementioned problem.

Combinatorial testing involves using multiple combinations of variables for testing, with the goal of this being to verify which/how many inputs of test data, with this information then being used to design future tests. Some of the benefits of combinatorial testing include a larger coverage of possible test cases than normal testing, since multiple inputs are used, reduces the cost and effort of the testing process through the fact that it’s a faster method of testing, and avoiding redundancy, as combinatorial testing ensures that the same cases aren’t tested multiple times.

To better understand how combinatorial testing works, lets take a look at the author’s example. Say we’re trying to test a username and password functionality, and we decide we’re using combinatorial testing for this. Instead of each test case only including one username OR one password, like what would happen if normal testing was being used, each test case includes 1 username and 1 password from a pool of multiple usernames and passwords. For example, let the tested usernames be User1, User2, User3 and let the tested passwords be PW1, PW2. Then, test case 1 could be testing User1 and PW1, then case 2 would test User2, PW1, then case 3 would test User3,PW1, and so on. By doing this, every case would be covered with only 6 test cases, with the same case never being covered twice.

Other types and ways of implementing combinatorial testing are available as well. For example, the example listed above would be an example of manual combinatorial testing, where cases are manually selected from the pools of parameters, where in automated combinatorial testing, software or scripts are used to automate this process and create many test cases automatically. This is especially beneficial if there are many possible inputs, and manually picking each case would be too time consuming.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Recognizing the value of different types of unit tests

Unit testing is a very useful and secure way to stabilize the development process, but despite that, some developers forgo the testing process altogether. In Gergely Orosz’s blog entry, “The pyramid of unit testing”, he covers the relationship between the time it takes to notice the benefit of certain types of unit tests, and the experience of the coder designing the tests. For example, a coder with limited experience may look at a code body, see there are no obvious problem cases to be caught by unit testing, and forgo the process, while an experienced coder may see the same code and choose to design tests for it for reason that aren’t as obvious, and that are more based on experience and intuition.

Gergely details 5 different tiers of the Pyramid of Unit Testing Benefits, with the tiers lower on the pyramid listing benefits that can be noticed immediately, and tiers higher showing benefits that are only noticed in a later stage in development. The lowest tier are the benefits offered by tests designed to validate code changes. These tests are purely designed to validate recent changes, and make no attempt to catch future cases that might not be a problem now, showing an immediate benefit compared to not testing. The next tier up is the benefit of separating concerns in your code, which serves to somewhat force the coder to write clean code, since if a code is to be testable, that usually means that dependencies are declared upfront, leading the code to have an easier to follow structure. The next tier is the benefit of having an always up to date documentation. Well written tests can serve as useful documentation for code, and, unlike documentation of implementation code, these tests won’t get out of date. The second to last tier is avoiding regressions. If changes are made to a code body with no unit testing, than regression and conflicts are more likely to be introduced compared to a code body with tests. Designing tests helps avoid this by catching these regressions/conflicts before they become problems. The highest tier of the pyramid is using tests as a refactoring safety net. While testing is useful for validating small changes, it’s equally as useful for providing a stable environment for refactoring. When required to make large scale changes, a developer is more likely to be comfortable changing a code body with a large amount of coverage over many unit tests, rather than a code body with no means of catching problem cases.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.

My Look into QA Testing

Hello, Debug Ducker here and this time I got interested into learning about QA testing. This sudden feeling of wanted to know more about this field came from my time spent watching online entertainment. In a lazy afternoon I decide to watch a gaming podcast, and found out that one of the host of the podcast was QA tester and worked on several games. His stories about his time in the business intrigued me a lot and made me do further research on what the job of being a QA tester requires. What I found is very interesting and hope you find it interesting too.

Let’s start off with what QA testers exactly do. QA testers is to make sure a product meets quality and legal standards and how they go about it is by using automated test with the purpose of making the program malfunction of break. This helps development teams as they find the issues that need to be address while still focus on the development of the product.

What I found interesting is that QA testing is that they perform a method of testing known as black box testing. They can’t see the code but still test its functionality. In my time studying software testing I was thinking of the possible reasons on to why would I test something that I can’t see. I realize now that if you can’t see the code you don’t have any preconceived notions on how it should function. If you had someone else, like a QA tester test it they would attempt to break things easily as they don’t ahve the idea of what the code base looks like. They are the unbiased viewer. Which can help a lot. I remember when testing for software there would be this one thing I didn’t account for based on my own assumptions and my code. Which lead to many annoyance and headaches.

QA testing is a very important aspect of software development. It helps find issues that can be missed and can keep a project manageable and focus when there is an entire team focus on testing. QA testing can save a lot of time too which can be very important for a project.

Maybe one day I can tell you more about the podcaster and his foray into QA testing as he has a lot of interesting stories to tell.

Thank you for your time have a great day.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Test-Driven Development

Hello! Welcome back to my next blog post. This post is about Test Driven Development, also known as TDD. I used this article to do some research on it: Test driven development: What it is and the benefits of using it

I chose this article because it goes into further detail about what we already learnt about in class. I chose this topic because we just went over it in class recently, and we also had a homework assignment on it. At first, I was very confused on what to do in the assignment, and I had no idea what I was supposed to put in the testlog file. But by the end of the homework assignment, I kind of understood everything more, and realized that the testlog file was just meant to help me organize my test backlog, and make all of my commits with notes left behind. It took me a lot of time to come to these realizations, but once I did it helped me a lot.

This article talks about something we briefly went over in class, called the “red-green-refactor development cycle.” What this means is that first you want to write a test, which you already know is going to fail – This is the red part. Then, you want to write very simple code; Just enough to make sure the test you wrote passes – This is the green part. Finally, you want to refactor your code, and make sure not only the first test passes, but also all of the previous ones as well. Refactoring is probably the most difficult part of the process, since the other two are sort of bare minimum procedures.

I was instructed to do this in the homework assignment, but with Test Driven Development, you are supposed to only do one test at a time. I think this is smart because sometimes you can get ahead of yourself or get lost while you are trying to make multiple tests pass at the same time. Sometimes with coding I feel like you can make more mistakes trying to be fast, which ultimately slows you down. While if you take it step by step, it actually could end up being quicker than if you are rushing and not being careful.

Overall, TDD is a very interesting topic, and it was helpful that we not only went over it during class time, but also had a way to practice this with the Kata homework.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

How Test-Driven Development Changed My View on Coding

The article I selected is titled What is Test-Driven Development? It explores TDD, which stands for Test-Driven Development. A software development methodology where tests are written before writing the actual code. At first, this idea sounded very backward to me, especially as a student still learning how to code. Originally introduced by Kent Beck in the 1990s, TDD follows a specific cycle: first, you write a failing test for a small piece of functionality. Next, you write the minimal amount of code needed to make that test pass. Finally, you refactor the code while continuing to pass all the tests. This method aims to create reliable and well-structured code from the very beginning.

I chose this article because while working on the TDD assignment for class, I found myself very confused about why the process was designed this way. It felt unnatural to write tests before even having code to test. After reading a few articles, including this one, I learned that the main purpose of TDD is to reduce the amount of time spent debugging and to automate testing early. It helps ensure that the code behaves correctly as new features are added, reducing bugs and saving time later.

After practicing more during the assignment, I began to see the benefits firsthand. I enjoyed the process once I understood it better, even though there were moments when I had to refactor my code multiple times to make all the tests pass. One important takeaway from the article was how TDD encourages continuous improvement. As developers write more tests, their code quality naturally improves over time. I also learned that TDD plays an important role in Agile workflows, pushing developers to prioritize testing before writing large chunks of code. This mindset shift promotes creativity, collaboration between developers and QA testers, and reduces technical debt, making it easier to maintain and update code in the future.

This article and topic really changed how I view software development. It showed me that TDD can be both a creative and collaborative process rather than just a strict set of rules. I now plan to apply TDD practices in my future career. By writing tests first, I can better organize my development process, catch issues early, and build more reliable software. Exploring this topic helped me overcome my confusion during class and appreciate why Kent Beck created this approach in the first place.

Reference:
Moore, Paul. “What Is Test-Driven Development?” Scrumalliance.org, 2023, resources.scrumalliance.org/Article/test-driven-development.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.