Test driven development is an important method of developing which is based on first writing a test for what you want your program to do, this test will fail as you do not have any code written in orde for the test to pass but you then write the code which is necessary for the test to pass and then you continue repeating this process of writing a test then writing the code for said test to pass. You are encouraged to write the simplest possible code in order to make your test pass before moving on to the next test but you may need to do some refactoring between tests in order to ensure you do not have unused code, confusing methods or variables, etc. Test driven development is very helpful when it comes to testing the specifications of a system as you can write simple unit tests which would pass if a specification was met and when it fails you know that you still must add or change your code in order to make sure the specification was met for the end product. Other types of testing are also important to perform but test driven development can help you steer away from over complicated code and make sure that you do not have recurring duplication present when you regularly refactor between cycles.

I found this article to be particularly helpful when researching test driven development as it clearly breaks down the steps of test driven development in order for the reader to fully understand the process you must go through in order to follow this development method. Along with the thoroughly explained process this article also compares and shows how both acceptance test driven development and developer test driven development work together. As we just started working with test driven development in class I found this article to provide valuable insight into the definition and process of this testing/development model as it is something rather different compared to what we have worked on previously regarding testing as we usually have worked with code that needed tests written and not with tests that needed code to be written. Being new to TDD made it seem very confusing at first as it did not feel right to be writing the tests for code which did not even exist yet but the benefits of TDD are much easier to understand once you put this method into practice.

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.

For this week’s blog, I decided to find a blog that discusses test-driven development (TDD). I found a blog called “Test Driven Development is the best thing that has happened to software design” by Arek Torczuk. In this blog, the author walks through how they apply key elements through real examples. Throughout the blog, they explain their reasons for implementing TDD and walk through how to use TDD on code that is impossible to test. They split their explanation of how to test impossible code into small sections that include bits of example code to aid in the explanation. I found the organization of the blog along with the various examples to be particularly helpful in aiding the reader understand the topic and stay engaged.

The author first explains that TDD is implemented in a fail, pass, refactor cycle approach. They shorten the idea by explaining that “our focus remains on the ‘what’, and our knowledge of ‘how’ is postponed.” In this section, the author also provides a visual which I find to be effective in blatantly pointing out the important details of this section. They then go on to explain the differences between when tests are driven by code and when code is driven by tests. When tests are driven by code although the tests written for the code may pass it may not be the right approach as feedback about implementation and design may be lacking. There are 2 questions that one has to ask themselves when they take this approach: “When should I stop adding new tests?” And “Am I sure the implementation is finished?”. The latter approach (when code is driven by tests) forces you to ask yourself “What do I expect from the code?”. When code is driven by tests, you know when to stop. TDD provides fast feedback.

The various examples of code that are impossible to test were interesting to read through. One example I found fascinating was the “Bloated setup” and the “Mocking Hell” scenarios. The first scenario is where an object either has too many dependencies or the Single Responsibility principle has been broken. The author explained that in this case you should you should rethink your design. The latter is where a mock returns a mock that returns a mock.

Overall, I think this was an interesting read. I think reading through the various examples of how to test impossible code will be useful for the future as I will have to think through how to test different kinds of code and when I should rethink certain designs.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

This week’s blog will cover the main purpose of Object Oriented Testing and its usefulness. You most likely have heard the term “Object Oriented Programming”, which refers to a style of programming that utilizes classes, abstract classes, inheritance, polymorphism, concurrency, and more as a way of organizing code. These tools can be useful when dealing with multiple lines of code because it can be broken down into multiple files creating a more organized and readable product. Having a file with thousands of lines of code is a developers nightmare. Object Oriented Testing aims to test these systems and ensure they are behaving as expected. It is possible to have too much inheritance in a program, making it difficult to find where a piece of code is located, slowing down development. Unlike other test methods that primarily test function behavior, Object Oriented Testing analyzes the behavior of the entire class and its interactions with other files.

There are multiple techniques to Object Oriented Testing: Unit Testing, Integration Testing, Inheritance Testing, Polymorphism Testing, and Encapsulation Testing just to name a few. Unit testing refers to testing of individual components of the class before testing the interactions it has with other classes. Initially testing the classes functions will prevent scenarios where you can’t locate the bug in the program because there are too many inherited classes. An example is testing each function and ensuring the behavior. Integration testing refers to testing objects of different classes and ensuring they behave properly with all the components. Inheritance testing aims to test the relationship between parent and child classes. This technique of testing also tests overridden functions are properly implemented and are actually overriding the function. Polymorphism testing aims to verify that objects of different types can be used interchangeably. This type of testing ensures the behavior across all types of objects. Encapsulation testing tests access control and ensures the data being accessed is allowed to be accessed by the user.

The main benefits of running these tests is to detect defects early on rather than later in the development process. For this reason, it’s recommended to run tests throughout development. Object Oriented Testing ensures our project is modular, making it easier to maintain. In addition, it becomes easier to implement new features and classes without impacting existing code. Due to the never-ending demands of modern applications and the ever-evolving tech industry, the scalability of a program is crucial.

Blogs chosen: https://medium.com/@hamzakhan522001/object-oriented-testing-1f9619da40d0
and https://www.h2kinfosys.com/blog/object-oriented-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

In the world of software development, ensuring code quality is paramount. It’s not just about writing code that works; it’s about ensuring that the code is robust, reliable, and maintainable. This is where various testing methodologies and tools come into play. In this blog post, we’ll explore three crucial aspects of code quality enhancement in JUnit: Smoke and Acceptance Testing, Exploratory Testing, and Static Analysis.

Smoke and Acceptance Testing: Smoke testing, also known as build verification testing, is a preliminary test that focuses on ensuring that the most critical functionalities of an application work. It aims to identify fundamental issues that might hinder further testing. Acceptance testing, on the other hand, evaluates whether the software meets the acceptance criteria and is ready for release.

JUnit, a popular testing framework for Java, offers robust support for both smoke and acceptance testing. Through annotations and assertion methods, developers can easily write tests that verify the functionality of their code. By running these tests regularly, developers can catch regressions early in the development cycle, thereby ensuring a smoother development process and a higher quality end product.

For further information on Smoke and Acceptance Testing, you can refer to the documentation here.

Exploratory Testing: Exploratory testing is a hands-on approach where testers explore the software application without predefined test cases. Instead, testers rely on their domain knowledge, intuition, and creativity to uncover bugs and issues. While automated tests are valuable, exploratory testing can uncover issues that automated tests might miss.

In JUnit, exploratory testing can be facilitated through the use of parameterized tests and dynamic test generation. These features allow testers to generate test cases dynamically based on various inputs, enabling thorough exploration of the codebase.

To learn more about Exploratory Testing, you can explore the documentation here.

Static Analysis: Static analysis involves analyzing the code without executing it, typically to find potential defects or code smells. In JUnit, static analysis can be performed using various plugins and integrations with static analysis tools like FindBugs, PMD, and Checkstyle. These tools analyze the codebase for issues such as potential bugs, code style violations, and performance bottlenecks, providing developers with valuable insights into improving code quality.

For detailed information on Static Analysis in JUnit, you can refer to the respective documentation of static analysis tools and plugins integrated with JUnit.

In conclusion, leveraging Smoke and Acceptance Testing, Exploratory Testing, and Static Analysis in JUnit can significantly enhance code quality, leading to more robust and reliable software applications. By incorporating these practices into the development workflow, teams can streamline the testing process and deliver higher quality code with confidence.

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

When you go to write code, maybe you already know what you want the code to do, knowing what it should give you as outputs and answers, but you might not know how to go about writing the code itself. In test driven development, you start with writing the tests first, and then trying to pass those tests, slowly as you go. It sounds like a strange approach to it but it is not as bad as it sounds.

In this blog post, Arek Torczuk talks about test driven development, and how it is the best thing that can happen to software development. First, they start off by describing test driven development, where they say it is, simply, a failing phase, a passing phase, and then a refactoring phase. In the failing phase, we create a test that will fail. In the passing phase, we create or write code, minimal code, that will pass the test. In the refactoring phase, we clean up the tests. Typically with coding, you would write the code, and then write tests. However, Torczuk presents some problems with this way of code development, like when to stop writing tests, or when you are sure implementation is finished. With test driven development, they say there are benefits, such as when writing tests, it makes you ask yourself, what do you want the code to do. They say that you should know the answers to these tests before the code is written. They then go on to provide situations where code may be impossible to test, and how test driven development can be used to help that, like using mocking. They provide code examples with these too, to further help visualize solutions. They provide some additional sources at the end of the article in the event you would like to learn more about test driven development. 

This is a strange way to write code, and for those used to writing code before everything else, this can be a difficult adjustment. Personally, I found it fairly difficult to start, but afterwards I was able to write the tests, and then write the code to pass those tests, and then keep doing that. The tests do provide a build up of the code, instead of doing everything all at once, which was what Torczuk was trying to get at with his blog post. It allows the tests to provide the framework of the code and lay it out. 

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Recently in my Cs-443 class, Software Quality Assurance and Testing, we have been talking about unit testing using stubs. Honestly, I didn’t understand what stubs were during the classes themselves, but a blog called Why Stubs in Unit Testing Improve Integration Testing helped me understand what a stub is, as well as where and when it is used. In this blog written by Miroslaw Zielinski, he states ” Unit testing is more about isolating the function, method, or procedure, otherwise referred to as a unit. This isolation is done by stubbing out dependencies and forcing specific paths of execution. Stubs take the place of the code in the unit that is dependent on code outside the unit.” Stubs allow the person testing the code to test specific paths of execution within the code, allowing them to view different things such as if different parts of the code work and are reliable. I think that Zielinski gives a great example of why these stubs are used in his article. He states, “Once the stub is added, it will be consistently applied to the tested code. A user working on the “allocation failure” test case will have an easy way to install a special callback function into the stub, which will simulate the desired effect: allocation failure or do nothing since by default the stub returns a null pointer, which is expected for the test case.” This helped me understand why stubs are used, and the rest of the article helped me understand when they are used.

After reading more of the article, Zielinski began to explain why stubs are used. Although his explanation confused me a bit, I believe I got the jist of what he was trying to say. I believe that they are being used when you are trying to test lower-level modules while the upper-level modules have not been developed yet. Therefore you can use a stub, which acts like an upper-level module, in order to see how it will be treated. Zielinski also gives examples of when stubs aren’t good to use and what the limitations are “In instances where there’s not an original definition available for a stubbed function, what happens? How does the stub behave without a callback that defines the alternative behavior? The beauty of C/C++test is that it automatically detects this kind of situation. The stub will reconfigure itself during the test harness build time. It won’t call the original definition when no callback is installed and will return a safe default value.” I’m not really sure what he means by this, but I hope to learn more in the future.

Link: https://www.parasoft.com/blog/using-stubs-in-integration-level-testing/#:~:text=Unit%20testing%20is%20more%20about,on%20code%20outside%20the%20unit.

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

System testing is a process of verifying the end behavior of a software application. System testing finds any errors, spaces, and missing requirements that could affect the software’s functionality. This is usually done after all the tests are completed, it’s important to test the software before releasing it to users. System testing main goals are to reduce risks, prevent defects, verify the design, and validate the system. System testing is an important step in ensuring the software is of great quality before it goes live. Addressing and identifying the errors or issues before making the software live can reduce any risks and make sure that it works perfectly for the users. Verifying the functionality of the completed system will help determine if it meets the requirements specified for that system. This is the best way to prevent any defects, errors, and missing requirements. System testing is also used to check if the system has been designed correctly and follows all the specifications. The process of verifying the accuracy and completeness of the system is the main objective of system testing. It’s to provide confidence that the system meets all of its requirements and will run as expected.

There are different types of system testing to look out for and plan for such as setting up the environment for the test case, creating a test case, creating test data, and running the test case. It’s important to make sure that the environment is set up so that you can write test cases by making sure that it has the right tools and frameworks that will be needed. When creating the test cases it’s important to make sure that the test case has all the necessary details about what the test case is testing for as well as how it will test it. The test data is created in thought of the inputs and outputs for the test case. While creating the test data it’s important to cover all of the critical fields and that nothing is left out. When running the test cases you want to make sure that it puts out the correct output, it should show if it passed or failed. I chose this topic because system testing is important to make sure that our system meets the requirements and runs without any problems. We started working on test cases recently so I thought getting more information on system testing would benefit our skills and any questions that anyone might have.

https://blog.qasource.com/what-is-system-testing-an-ultimate-beginners-guide

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.