Category Archives: CS-443

Why Test-Driven Development Boosts Code Quality

In the fast-moving world of software development, one approach stands out for promoting cleaner code, fewer bugs, and better design: Test-Driven Development (TDD). Instead of writing code first and testing later, TDD flips the script β€” you write the test first, watch it fail, then build just enough code to pass that test.

πŸš€ What is TDD?

Test-Driven Development is a simple but powerful cycle:

  1. Write a failing testΒ (Red)
  2. Write minimal code to pass the testΒ (Green)
  3. Refactor the codeΒ without changing its behavior (Refactor)

This process repeats for each small piece of functionality. Over time, it builds up a fully tested, reliable system.

🧩 A Real Example: Word Count Kata

Recently, I practiced TDD while solving a classic coding exercise called the Word Count Kata. The goal was to analyze a piece of text, count the words, ignore case and punctuation, and even filter out unwanted “stop words.”

Here’s how TDD helped guide the process:

  • First, I wrote a test expecting the wordΒ "hello"Β to be counted twice inΒ "Hello hello".
    ➑ The test failed (as expected).
    ➑ I then implemented the countWords method to pass it by converting the text to lowercase and splitting words properly.
  • Next, I tested a sentence with multiple words:Β "Hello world hello again".
    ➑ I wanted to make sure the system counted "hello" twice, and "world" and "again" once each.
  • Then, I challenged the code toΒ ignore punctuationΒ by testing a sentence likeΒ "This, is a test!".
    ➑ The code had to split words correctly, even when commas and exclamation marks appeared.
  • Moving to an intermediate stage, I added “stop words” likeΒ "the"Β andΒ "and", and made sure they were excluded from the count.
  • Finally, for the advanced part, I created a sorted list showing the most frequent words first, such asΒ "again 3"appearing beforeΒ "test 2".

By adding each test one by one, my code grew naturally and remained stable.

πŸ”₯ Why TDD Matters

Through this exercise, I experienced firsthand why TDD is powerful:

  • Confidence:Β Every time I changed the code, I knew instantly whether I broke something because all tests ran automatically.
  • Clarity:Β Writing tests forced me to think about theΒ expected behaviorΒ before diving into coding.
  • Design:Β Since I only built what was needed to pass the next test, the code stayedΒ simpleΒ andΒ focused.

Rather than rushing ahead and debugging messy errors later, TDD helped me build my project brick by brick, with each piece carefully tested.

🎯 Final Thoughts

Test-Driven Development isn’t just for “perfect coders.” It’s a learning tool, a design assistant, and a safety net. Even on a small assignment like the Word Count Kata, using TDD made my work cleaner, more organized, and far less stressful.

If you want to level up your coding habits, I highly recommend giving TDD a real try β€” one failing test at a time.

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

Test-Driven Development vs Behavior-Driven Development

For this weeks’ log entry, I wanted to cover a topic that was a bit different from the post that I made last week. One topic that caught my eye as being a perfect option to learn more about was Behavior Driven, and potentially also Test-Driven, development of code. When researching this topic, I came across a podcast titled, β€œBehavior-Driven vs Test-Driven Development & Using Regex in Python” by The Real Python Podcast on spotify. One of the largest factors that drew me to choosing this podcast to learn from was the fact that it was made incredibly recently (only a few months ago).

TEST-DRIVEN DEVELOPMENT:

A process of developing code that revolves around writing automated tests for code before ever actually writing the code itself. The process starts with a programmer writing a test for some sort of new feature that they want added to their code or that they want their code to be able to solve. After this, they write the smallest amount of code that they possibly can in order for that test to pass, potentially refactoring after the test is passed if they feel a need to do so. TDD originated before and was used to heavily inspire the agile process and scrum methodology that we see used today. TDD can be a helpful process to follow for several reasons. First, it ensures that you have actually written good tests and helps to mitigate any sort of temptation to cut corners when working on a project. TDD also helps teams to work specifically within the realm of what is being asked of them, rather than β€œgold-plating” their work and adding other features to their code that may not have been asked of them. Overall, TDD is very structured and easily provides a path for workflow to follow without confusion.  

BEHAVIOR-DRIVEN DEVELOPMENT:

BDD for short, in a way it is an extension of TDD, only focusing on the highest levels of the testing pyramid and involves Acceptance Test Driven Development. Essentially, before you ever write the function that you would use to test in TDD, you first write tests about how you think the application is actually supposed to behave. It focuses on a feature behaving in a particular way as opposed to that same feature returning a particular response. First, you would identify things that your code would need to create some sort of list that can be used to define what needs to be done or whether or not that feature is properly working. After identifying the need, you would write high level tests to check this. Same as in TDD, you would essentially be writing the code in parts, running tests in between to ensure that the code being written is being done so with an immediate purpose and goal to achieve within the project.

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Mastering Test-Driven Development

For this blog post, I’d like to discuss an interesting piece by Jeremy D. Miller titled “Effective Test-Driven Development”. It provides some practical tips and advice for developers on how to make the most of Test-Driven Development (TDD). I found it very relatable because it relates to what we’ve been discussing in our software development class, particularly testing and keeping our code in good shape.

Miller’s article delves into TDD, which entails writing tests before coding. While TDD is a common method, he explains how to avoid common issues and adhere to best practices. He discusses how too much setup code, slow feedback, and unnecessary tests can all contribute to slow performance. He contrasts these issues with good habits such as writing quick tests, providing timely feedback, and ensuring tests are clear about what they check in the code.

Miller also discusses how TDD can help with design and quick feedback. He mentions that TDD encourages developers to plan out how their code will look, making it easier to maintain and less buggy. The goal is to make testing an integral part of development rather than a final step, so that problems can be identified early.

I chose this blog because we had only touched on TDD in class and I wanted to see how it applied in real-world software development. I thought it was fascinating that TDD is about more than just writing tests; it’s also about improving code structure. Miller’s suggestions are ones I’d heard of but hadn’t looked into thoroughly. His advice helped me understand how TDD can improve code quality and make life easier for developers, which is extremely useful to me as a student learning to write solid code. Reading this blog made me realize how important it is to write tests that do more than just check if things work; they should also ensure that the code is easy to change later. Miller, for example, discusses “happy paths” in which tests check for expected results and “negative tests” in which errors are handled. This is consistent with what we’ve been learning about testing, but it also gives me a better understanding of how TDD can help clean up and improve code over time.

Miller’s post emphasizes the importance of not rushing through TDD. It’s better to take your time and write clean, manageable code. I found this extremely useful because, as a beginner, I frequently feel the need to complete tests quickly. But Miller reassured me that taking it slowly can save time in the long run by identifying problems early on.

I intend to use TDD more actively in future projects. By writing tests first, I can keep the end goal in mind from the start, reducing the need for major rewrites later. I also feel more confident about refactoring because TDD will help me keep the code solid while I make changes.

In the future, I want to incorporate Miller’s concept of clear intent expression into my code. Writing tests that clearly demonstrate what the code is supposed to do will simplify things for others and help me stay focused when working on larger projects.

Blog: https://jeremydmiller.com/2022/10/03/effective-test-driven-development/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

The Importance of Teamwork in Software Testing

While teamwork may not be listed as one of our topics for the course, if I’ve learned anything during this semester it’s that teamwork yields massively more results than testing alone. We just recently did an assignment where we were given “shaky” code to look at and record any errors we found. We started by going off on our own to look for errors. We then came back together to see what everyone found, and it was amazing how different our lists look. Even though it was the same code everyone caught a ton of different mistakes.

There are plenty of benefits to teamwork in the software testing field. “The Importance of Collaboration in Software Testing Teams” is a great blog I discovered that fully goes over these benefits. Unfortunately, the author did not leave their name anywhere and signs off as “admin” so I can’t give them the full credit due, but I linked the blog above if you want to give it a read over.

Some key takeaways are early issue identification, improved software quality, and increased efficiency. There’s many more listed in the blog, but these are the three I find most important.

In one of my previous blogs, I mentioned just how much more it can cost to fix a mistake that slips through the early phases of software development so having early issue identification is huge. Through multiple eyes looking at the same software everyone is able to use their own unique perspective to weed out as many bugs as possible.

As for improved software quality and efficiency, how can you not say yes to better software, faster. That’s just a win for everyone. Every developer has their own style and methods to solving problems and by combining them you can create innovative solutions that can drastically increase efficiency while creating more sound programs.

Teamwork has been a large part of my computer science degree at Worcester State. I plan on continuing to sharpen my skills as both an individual and a teammate as I progress through my career both academically and professionally.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

The Benefits of Test Driven Development

TDD or test driven development is a method of building software by creating tests first and then writing the implementation of the code. This blog breaks down what TDD is and the steps to the process. TDD aims to help developers build a program that meets the requirements. By building to meet certain criteria, programmers will always keep the goal in mind. Building with certain behaviors or outputs in mind. The first step is to write a test list. Essentially you are writing tests with the end behavior in mind. It is writing tests, but this stage is also an analysis. An analysis of what the programmer or team or whoever thinks the final program behavior looks like. The next step is to write a test, one that is robust and fully implemented. With one test implemented, the program implementation is now taking shape. Because the program must be made in a way so that it will work for the test. Now that you have a test, the next goal is to make that test pass, by any means necessary. After that you can refactor depending if the tests or implementation needs to be changed to make the program better. Then it becomes a matter of repeating the process until the test list is through.

I think TDD is a very interesting approach to programming. Usually we think of the typical process of build first and then testing. But TDD reverses that, and it creates a very dynamic when it comes to building software. I never really thought about it before but the way you build a test does affect the way the program is implemented. Like if your test is expecting a string or integers, you have to build the implementation in a way that returns those types. There are many ways to make a test that does the same thing. But those tests go about it in a different way. Thus that changes the way you program the implementation. I also think TDD adds focus and direction to programming. As you always know what you need to return or what the expected output looks like.

https://tidyfirst.substack.com/p/canon-tdd

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Black Box Testing

Black box testing is one of many testing paradigms in the world of testing. I think black box testing stuck out to me because it has the coolest sounding name. This blog is an overview of what black box testing is, when and where to use it, and the pros and cons. The main idea around black box testing is to test a program without knowing the inner workings of the program. Essentially you give the inputs to the program and receive the outputs. But you don’t know what’s going on in the in-between. Black box testing can also be split into even smaller forms that each serve a different purpose. For example, there is functional testing that aims to assess the program’s ability to return outputs that match the specifications. Another example would be system testing, which aims to test the program as part of a larger system. Testing to make sure that the entirety of the program works. Some of the pros of black box testing is that it simplifies testing because it focuses on user requirements. Cutting out on other factors to make sure that the user experience is good. Cons include limited test cases because of limited knowledge of the program. Tests are often simple due to the nature of the lack of information.

I think black box testing is an important part of testing because it’s testing based on the perspective of the users. Most users of an application don’t know the inner workings of said application. So making sure that everything is working on the user side ensures that the user experience is quality. After all, if the people using the application hate it, then they want to use it. And they probably dont want you to work for them again.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Making Code Stronger with JUnit 5

Blog Post: Making Code Stronger with JUnit 5

This week, I found a blog post called “Increasing Code Fortification: A Guide to Security Testing in JUnit 5”, and it gave me a new way of thinking about security in my code. I already knew JUnit 5 was useful for unit testing, but I hadn’t really thought about using it to test for security issues too.

The post talks about how developers can use regular unit tests to check for vulnerabilities early on, instead of waiting until the very end of development. It explains different strategies, like testing bad input, enforcing boundary checks, and even trying to break your own code to make it stronger. The idea of using parameterized tests to throw lots of different attacks at your code really stood out to me. I liked how the blog makes it so straight-forward.

Reading this made me realize I thought of testing as a question of”does it work?” β€” not “is it secure?” I like the idea of making security testing part of the normal coding routine, instead of something extra you only do if you have time. It’s a good reminder that security isn’t just about firewalls and encryption; it’s about the small choices you make in everyday code. The blog really emphasized that testing for edge cases and unexpected behavior can be just as important as making sure the “happy path” works.

One thing I found especially interesting was how JUnit 5 makes it easy to run the same test with multiple different inputs using parameterized tests. I had used this feature a little bit before for checking different types of valid inputs, but I hadn’t thought about using it to simulate attacks or unexpected bad inputs. For example, passing in SQL injection strings or unexpected data types could help catch vulnerabilities early before they become serious security problems.

I also liked how the blog encouraged starting small, not talking about designing a full-blown security test suite right away. Even adding a few security-focused tests for each feature you write can slowly build a stronger, more resilient application over time. It made me think about how easy it is to treat the idea of “security” as something separate from “normal” code and how easy it is to break it down into a couple tests per feature makes it much more manageable that coding the project and then trying to apply security testing.

In my future projects, especially ones involving databases, user input, or authentication, I want to make sure I’m thinking about security from the start. Testing with bad input and thinking like an attacker isn’t just for cybersecurity experts β€” it’s something every developer should get comfortable doing. Using JUnit 5 for this feels like a natural extension of skills I’m already using.

Overall, this blog post made security feel a lot more approachable. It gave me some simple ideas I can apply right away, and it motivated me to be a little more critical and thoughtful about the code I write, not just whether it works, but whether it’s strong enough to handle real-world problems.

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

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.