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.

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.

Reviewing your code is important, it makes sure that the code is correct and functions the way you want it to. Code review helps cover so many areas of your code. You want to make sure that your code is understandable for anybody else who looks at it and that it’s clear, by reviewing your code you can go back and fix anything that could be making your code more complicated. Code reviewing is important when working with a team, your team should understand what your code is trying to execute without being confused. When it comes to coding so much of your work can change throughout the process which is normal but with so many changes happening it can get confusing. Code reviewing comes with so many different solutions when it comes to writing code it nitpicks what parts are important or not. It’s a helpful tool that helps coders make sure they have clean code and that when working with a team everyone’s comments are heard and changes are made.

Code reviews can be tough if the team isn’t together so questions and comments can’t be answered. Another thing is that the code could be overlapping, and missing a team meeting could affect the code and confuse team members about what they should be writing ending up in similar code. If that happens the next person reviewing the code will find duplicate code and will end up pushing the team’s work behind. Making sure your team communicates will help prevent more code from having to be fixed and reviewed even though you don’t want to add more work on top of what you already have. Code review makes sure your work is good quality and organized. Having sloppy issues and mistakes doesn’t look good for you, your team, and your job. Code review is about making sure your work is organized and clean, you want to make sure you put out good work without having a lot of issues. Especially as a team you want to meet those standards and follow them. Always make sure to review your code because there could be small errors or even confusing comments that will make your code more complicated than it needs to be.

https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose the article “Code Review Best Practices – Lessons from the Trenches” by Drazen Zaric. I chose this article because its topic fits perfectly with the cove review segment in the syllabus. This article discusses why you should do code reviews, how code reviews act as quality assurance, how code reviews function as a team improvement tool, how to prepare a pull request for preview, and, of course, how to review code. In this article, I will be discussing why you should do code reviews and how they work as quality assurance.

Reviewing code is one of the most essential parts of the development process. “It should be obvious that the primary purpose of code review is to assess the quality of the changes being introduced. I mean, the dictionary definition of review says precisely that ‘review (noun) – a formal assessment of something with the intention of instituting change if necessary.’ Of course, code being code, there’s a lot of things that can be checked and tested automatically, so there’s nuance to what needs to be checked in an actual code review.” As mentioned in the article, there are many things that can be tested and should be tested. This leads to a need for many people to review your code, and you will need to review many other people’s code to make sure the best possible software is being developed. Quality assurance must be done well as a significant part of making sure your software is the best it can be.

In this section of the blog post, I will discuss how the article mentions how code review is incredibly useful in quality assurance. “There are many ways in which code reviews help maintain the quality bar for the codebase and the product. In the end, it comes down to catching mistakes at a level that can hardly be automatically tested, such as architectural inconsistencies. Also, the code for automated tests should be reviewed, so there’s a meta-level at which reviews help with QA.” As mentioned, code review’s main boon to quality assurance is finding issues that can’t, or often need to be caught, through traditional testing methods, like automated testing. The article also mentions using checklists for storing what needs to be checked and how and what the results of said checks should be. “You can have your own checklist or make it a shared list for the team or a project. There’s a ton of material written on the usefulness of checklists. In Getting Things Done, David Allen puts forward a simple idea – our minds are great at processing information but terrible at storing and recalling it. That’s why checklists are a great way of externally storing and breaking down a planned or repetitive task.” Having a method of keeping track of what is done, what needs to be done, and what is incomplete is essential in working on any large project, let alone on a software development project.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The blog post highlights the qualities as well as the differences between these two types of testing, static testing and dynamic testing. I chose this blog post because as this course covers software quality assurance and testing as well as the fact that we have spent time in class covering these two types of testing I believe that this blog post is able to highlight and reinforce core concepts that will be able to assist in gaining further knowledge withing this class. In addition, the blog post is able to explain the information regarding static and dynamic testing in a simple and easy to understand format that further compliments the idea of using this blog post as a resource to reinforce these topics.

The blog post as previously discussed covers static testing vs dynamic testing. We learn that static testing involves testing the code without actually running it while dynamic testing involves running the code to test it’s outcomes through various testing circumstances. From those two descriptions we can tell how static testing relies on testing through software documentation as well as the design of the code itself. However, dynamic testing is able to execute the program allowing the testers to test how the code will work in an assortment of testing scenarios. This concept allows testers to see how the code will work once it is released to the public to verify that it works as intended. These two types of testing are very different in their methods of achieving a successful test. Static testings wants to identify problems and improve on them early in development while dynamic testing wants to validate the performance and functionality of the code once it is in a executable state. Since they have different intents your requirements for the project is what determines what testing you will choose.

From what I have learned from the blog post I believe it was very helpful and was able to reinforce core concepts that will help me further in this class. I believe learning more about static and dynamic testing will help me when it comes to working in this class as well as assist in knowing how to test in a professional setting. Knowing the core differences between the two will allow me to know what type of testing will be best for certain circumstances when it comes to projects. In conclusion, this blog post was very helpful and will be utilized in the future.

https://testsigma.com/blog/static-testing-and-dynamic-testing

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

A Critical Component of Software Quality Assurance

I was based to this blog: https://www.celestialsys.com/blogs/software-testing-boundary-value-analysis-equivalence-partitioning

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