Test Driven Development (TDD)

Test driven development is a form of testing done in software development that focuses on creating unit tests before the actual code. Developers create small test cases for every feature with the intention of modifying the code only when the tests fail. Test driven development is also a practice that focuses on the structure of the code that allows for the creation of optimized code that remains reliable over time.

TDD vs Traditional Testing

As stated above, one of the main differences between TDD and traditional testing is that tests are created before the actual code unlike traditional. However some other differences include the testing scope and the processes that each form of testing follows. The testing scope in TDD focuses on testing small, individual pieces of the codebase whereas traditional testing tests the entire system including integration testing. The process of each type of testing also differs in that TDD is an iterative process. As tests are created, this process also includes cycles of developing small chunks of code, testing that code, then refining until all tests pass. An important part of the TDD process is refactoring. Once tests pass, it’s important to check the code if there are any optimizations that can be made, or if there is any redundancy that should be removed.

Benefits to TDD

Test driven development allows for the creation of optimized code by nature because of the process that TDD follows. Once code is written, if the tests fails then the developer is forced to go back and fix the code until the tests pass. The test coverage that TDD covers is greater than traditional testing methods. This is because before any code is written for a specific functionality, the test is created beforehand which ensures every function passes testing. Using test driven development also helps in reducing the number of larger, more complex issues that arise. This is because testing is done on a consistent basis, where development does not progress until each set of tests are complete.

Conclusion

I chose this article because it clearly explained what test driven development is, differences between traditional and test driven development, and the benefits. I also appreciated the use of examples the article used to further explain what the TDD approach would look like in real scenarios. Learning about different approaches to developing software is helpful because I am exposed to approaches that could be more useful than what I already know. I plan to try test driven development in the future.

Resources:

https://www.browserstack.com/guide/what-is-test-driven-development

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

Article: https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

Last class, we got some hands-on experience with using Test Driven Development. These concepts always feel more concrete and understandable when actually working with them  yourself, rather than only reading articles or looking at examples. I’ve since gotten the hang of this method of development, and wanted to look into how it compares with other development strategies. Such is how I found Test Driven Development is the best thing that has happened to software design by Arek Torczuk.

Throughout the entire article, Torczuk compares the methodologies of code-driven tests and test-driven code. In other words, he judges whether code-first test later is better than test-now code later, respectively. The results for this vary, of course; some companies or teams may benefit more from one strategy than the other. A noted flaw of code-driven testing is that your tests do not challenge the implementation and design of your code. You can create all the tests you’d like on a specific method, but nothing would make you second-guess the way you wrote the method. 

This is where the test-driven approach would come into play. Having already written the tests, you have a better idea of what your code should look like, and how it should act. As Torczuk states, you can ask yourself “What do I expect from the code?” with writing tests before the method (Torczuk). Essentially, with TDD, you know all the answers to your questions and when enough is enough in terms of tests & code. In my mind, it makes the process more streamlined.

Another important part of TDD Torczuk mentions is that it gives quick feedback about the design of your software. You’ll sooner realize the potential issues with your existing codebase, and how it might affect your ability to add new functionality. 

I selected this article because test-driven development piqued my interest after I had more time to experiment with it. This article grabbed my attention specifically because it didn’t just reiterate the concept of Test Driven Development over and over. Another quite useful part of this article is its inclusion of real examples of TDD by the author.

The content of this article was clear cut and organized, and even though it may not have been a ton of new information, it was a different perspective comparing test-driven development and code-driven tests. I learned that generally TDD is more effective at producing well-implemented code than simply writing the method first and tests later. Seeing as we are continuing to learn TDD, I’m confident that I’ll be able to use this in my future projects/jobs if necessary. Or, I could suggest it to my team if we are struggling with writing tests after code.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Software testing != doing homework bt rather, Software testing == checking homework to make sure it’s done right. In this blog we’ll explore the basics: what testing is, how it’s done, and why it’s important. We’ll cover different ways to test, how deep we go into testing, some smart ways to test, and why testing is worth it. Let’s dive in!

What is Software Testing?

Software testing is the process of verifying and validating whether a software or application is bug-free, meets technical requirements, and satisfies user needs. It ensures that the software functions as expected, identifying errors, faults, or missing requirements in contrast to actual specifications. This process aims to enhance efficiency, accuracy, and usability.

Verification and Validation

1. Verification: Ensures that the software correctly implements specific functions, answering the question, “Are we building the product right?”
2. Validation: Confirms that the built software aligns with customer requirements, answering the question, “Are we building the right product?”

Different Types of Software Testing

1. Functional Testing: Validates whether the software functions according to functional requirements.
2. Non-functional Testing: Assesses non-functional aspects like performance, scalability, and usability.
3. Maintenance Testing: Involves modifying and updating software to meet evolving customer needs.

Further, testing can be performed manually or through automation, each with its own set of advantages and applications.

Different Types of Software Testing Techniques

1. Black Box Testing: Conducted without accessing the source code, focusing on software interface.
2. White Box Testing: Involves knowledge of internal workings and access to source code.
3. Grey Box Testing: Blends aspects of both black and white box testing, providing testers with partial knowledge of the internal workings. This approach offers a balanced perspective, allowing for effective testing while maintaining a degree of independence from the code’s intricacies.

Additionally, Grey Box Testing combines elements of both approaches.

Different Levels of Software Testing

1. Unit Testing: Evaluates individual units or components of the software.
2. Integration Testing: Tests the interaction between integrated units.
3. System Testing: Assesses the complete, integrated system or software.
4. Acceptance Testing: Determines system acceptability based on business requirements.

Each level serves a distinct purpose in ensuring software reliability.

Best Practices for Software Testing

• Continuous Testing: Test each build as it becomes available to reduce risks and improve functionality.
• User Involvement: Engage users to understand their needs and perspectives during testing.
• Test Segmentation: Divide tests into smaller parts for efficient analysis and resource utilization.
• Metrics and Reporting: Track project metrics and share test results for improved collaboration and decision-making.
• Regression Testing: Continuously validate the application to maintain its integrity.
• Avoid Programmer Bias: Programmers should refrain from writing tests to maintain objectivity.
• Service Virtualization: Simulate systems and services to reduce dependencies and start testing sooner.

Benefits of Software Testing

• Product Quality: Ensures delivery of high-quality software by detecting and fixing errors early.
• Customer Satisfaction: Identifies and resolves issues before delivery, enhancing user experience.
• Cost-effectiveness: Saves time and money by detecting and fixing bugs in early stages.
• Security: Protects software from internal and external security vulnerabilities.

Sources – https://www.geeksforgeeks.org/software-testing-basics/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

In another of my classes I am beginning to learn android mobile app development. This gave me a lot of interesting thoughts about how testing might look for mobile app development. As the applications are full-stack applications, and require testing of the back and front ends. I had questions like: “What would testing a front end look like? Simply applying it and clicking around?” and “How might we test back-end functions if they are intrinsically tied to the front-end?”. To find out more I looked on stickyminds, where I find most of my articles. I found an article about Testing Usability in Mobile app Development The title struck me as answering the first of my questions, so I chose to delve into it. The article’s title is Testing Usability for Mobile Applications by Mukesh Sharma.

The article provides an in-depth analysis of the pivotal role of usability in mobile applications. Usability has a profound impact on user engagement and app longevity, and this is something I can corroborate, as I have chosen apps with higher usability over similar apps with better quality and functions, but lesser usability. The article highlights specific usability characteristics: app simplicity to facilitate navigation effectively, helpful error handling mechanisms to guide users through troubleshooting and make it less of a hassle, optimizing efficiency to speed up tasks, and prioritizing user satisfaction to keep the app functional and supported by users. The article also delves into the nuanced focus areas for usability testing, including functionality assessments to verify feature completeness, contextual evaluations to tailor experiences to user preferences and test them against other preferences, rigorous device compatibility testing to ensure seamless performance across diverse models of mobile device and OS, examining in detail and scrutinizing data entry methods, and comprehensive examination of multimodality, to avoid user uncomfortability. The article uses an example of the Skype app to explain these potential problems. When moving the phone away from your ear, it would switch the speaker in your phone from the call speaker, to the loud back speaker. This is similar to the function in my Samsung Galaxybuds. When you take them out of your ear, it stops what’s playing or disconnects entirely. These are examples of uncomfortable features that have not been tested fairly. By adhering to the best practices for testing, developers can fix these issues in the testing phase, and assure no issues come from the software.

This applied extensively to several of my classes. I had been wondering how to think about tailoring mobile applications to the user, since learning about their development in one of my classes. This article has given extensive explanations into some poor features, and how to test to avoid these issues in the creation of the app. This will be very useful not only for mobile applications, but for testing full-stack applications as a whole, as the article covers mainly abstract ideas for testing full-stack applications.

Source:
https://www.stickyminds.com/article/testing-usability-mobile-applications

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

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.