Test-driven development (TDD) seemed odd to me when I was first introduced to it, much like the majority of others. The idea of writing tests before code felt weird in a way, as you write tests for nothing. However, the more I read about the benefits and how to properly apply TDD, the more obvious it was how useful TTD really is. Jacob Schmitt does a great job explaining TDD along with its benefits and best practices in his blog “Test-driven development (TDD) explained” (https://circleci.com/blog/test-driven-development-tdd/).

What is Test Driven Development?

Test-driven development is a software development approach where tests are written before code. It follows an iterative cycle: write a test, ensure it fails, write code to pass the test, and refactor. This means that a large amount of planning needs to go into the start of a project. Designing tests requires an understanding of what the feature you are adding should accomplish. This includes testing that things should pass when expected and fail when expected.

What Does Writing Tests First Accomplish?

As I mentioned before, it feels counterintuitive to write a test for code that does not exist. That is, until you understand the benefits of having tests. Tests are going to be required for any serious project. Having the tests written first will greatly increase your chances of finding bugs as early as possible. This also ensures that any refactoring does not break any existing functionality. This is great when working with a team, ensuring that everyone is on the same page and that changes made by anyone will be tested. TDD also ensures that all code that is written is tested. This greatly increases the code reliability and ensures functionality aligns with the user expectations.

Benefits of TDD

One of the most impactful benefits of TDD as a developer is the increased confidence that any changes you make in the code will have immediate feedback on if it passed the tests or not. This confidence extends to every developer on the team, as these tests ensure everyone’s code works as intended.

Catching bugs early can save a huge amount of time and money. It makes sense that testing code incrementally as it’s added is better than waiting until it is all developed to test. This also makes sure no code is ever added that isn’t tested. Meaning tests are being rushed near the end of deadlines, and potentially missing some.

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

As a student of computer science, encountering different tools that streamline coding processes is a cornerstone of my educational journey. One such tool that has caught my attention this semester is pytest, a testing framework for Python that allows for simple unit tests as well as complex functional testing. After a thorough exploration, here’s why I believe every budding software developer should dive into pytest’s documentation.

Why I Chose This Resource

The reason I chose to delve into the pytest documentation is twofold. Firstly, our course has increasingly emphasized the importance of test-driven development (TDD), a method pytest excels at supporting. Secondly, several industry professionals I look up to have recommended pytest for its simplicity and efficacy, making it an essential skill in a developer’s toolkit.

Summary of the Resource

The pytest documentation provides a comprehensive guide to getting started with pytest, from installation to writing your first test. It covers key features like fixtures for a scalable and modular setup, markers for categorizing tests, and plugins to extend pytest’s capabilities. The documentation is well-organized and rich with examples, making it accessible to newcomers and a valuable reference for experienced developers.

Personal Reflection and Application

Reading through the pytest documentation was an enlightening experience. It not only clarified the mechanics of pytest but also underscored the benefits of using such a tool in real-world programming. One of the standout sections was on ‘parametrized testing’, which illustrated how to execute multiple permutations of a test with different input sets, ensuring broader coverage with fewer lines of code.

This resource has profoundly affected my approach to programming. It has instilled a more disciplined mindset towards testing, making me appreciate how early detection of issues can save time and resources in the development cycle. I now plan to integrate pytest into my upcoming projects, confident that it will enhance the quality and reliability of my code.

Future Practice

The knowledge gained from the pytest documentation is something I intend to apply in all my future software development endeavors. I see it as a step towards adopting best practices in testing, which is vital for any aspiring software engineer dedicated to producing robust and fault-tolerant software.

Conclusion

For any student of computer science, understanding the tools at your disposal is as crucial as mastering programming concepts. The pytest documentation is a goldmine of information that promises to elevate your testing skills. I highly recommend it to anyone looking to embrace test-driven development fully.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

For our final assignment for the course, we are being tasked to create a sort of activity similar to the activities we have been doing in class this semester for my software testing course. In working on this activity, we chose to write an assignment based on behavior driven development, using the Cucumber tool. As such, before we really get into the weeds of the assignment, I thought it would be a good idea to look into the tool myself and what behavior driven development looks like.

For today’s post, I’m looking at a blog post from Moisés Macero on The Practical Developer blog.

Firstly, behavior driven development is built for fostering communication and discussion around systems and how they should properly be working. Typically, the process is in three stages: discuss, capture, and write tests. We want to talk about what the requirements really should be between the product owner and developers, refine what our requirements and targets should be, then move forward to building the software and testing it.

What Cucumber does for this is introducing syntax, called Gherkin, to enhance the readability of tests even for people who don’t know how to read code. The syntax is styled in a format of ‘given’, ‘when’, ‘then’. You mark these test cases with keywords such as feature, scenario or example to accurately describe what the code should be doing and how it is being tested. One of the examples used in the article is the following:

  Scenario: Users solve challenges, they get feedback and their stats.
    Given a new user John
    When he requests a new challenge
    And he sends the correct challenge solution
    Then his stats include 1 correct attempt

Here, you can see that the syntax is (probably) easily readable and understandable even if you don’t have any software development experience. These statements are stored in .feature files, and act as sorts of definitions for tests.

For the actual testing, you apply these definitions by writing Cucumber expressions in a step definitions file. These are essentially files that not only test the code in a step-by-step approach, but also features readable headers for each function. Here’s an example of a couple of functions using Cucumber expressions (taken from this post in the same series):

    @Given("a new user {word} is created")
    public void aNewUser(String user) {
        this.challengeActor = new Challenge(user);
    }

    @When("they request a new challenge")
    public void userRequestsANewChallenge() throws Exception {
        this.challengeActor.askForChallenge();
    }

    @Then("they gets a mid-complexity multiplication to solve")
    public void getsAMidComplexityMultiplicationToSolve() {
        assertThat(this.challengeActor.getCurrentChallenge().getFactorA())
                .isBetween(9, 100);
        assertThat(this.challengeActor.getCurrentChallenge().getFactorB())
                .isBetween(9, 100);
    }

Cucumber supports a variety of different languages, and also supports testing frameworks such as JUnit, which means it is also very versatile and can be used alongside a testing driven development environment as well.

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

During this semester we have learned about many different testing techniques, some being a lot easier than others. One of the testing techniques that we have learned is called Stochastic Testing. Stochastic testing is a type of black box testing method in which random tests are conducted over time. These tests are performed by automated testing tools in order to see if the software can pass a large number of individual tests.

Another type of testing technique that we have talked about is Property-based Testing. Property-based Testing is very similar to Stochastic testing. In this testing technique, the testing is also automated. However, it isn’t just executing the tests that is automated, it is also generating the tests. While researching the topic, I came across an article called “What is Property-based Testing?” by Alex Robert. In this article, Robert states “Property-based testing automates that work for us. Test automation allows us to generate better tests with less work and less code, so that we can focus our effort on the less mechanical work developers excel at. Instead of writing tests with manually created examples, a property-based test defines the types of inputs it needs. In the example above with CommonPrefix, the input would be two strings. The property-based test framework will generate hundreds if not thousands of examples and feed them to your test function.” He talks about how property-based testing can create a ton of different examples for your test function in order to help you test your program.

In this article, Robert also talks about input generators and what they do. A generator is a function that returns an instance of a given type from a source of randomness. These generators are great for randomly creating new inputs for the test function. However, they are only efficient if the generators have a good framework in order to help uncover more issues with the code. Robert gives a list of qualities that he thinks would make a good generator. His qualities include: a generator should be fast, a generator should be deterministic, a generator should not waste randomness, and a generator should cover the code under test. Most of these property-based testing frameworks come with a built-in generator which can be extremely helpful for testers, depending on the type input parameter. I really enjoyed reading this article as looking at all of the examples given by Robert helped my understanding of the topic. I know that if I ever need to use this type of testing technique, I will definitely use this article as a reference.

Link: https://www.mayhem.security/blog/what-is-property-based-testing

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.

The blog post, “Unit Testing Best Practices: 9 to Ensure You Do It Right” focused on highlighting important habits and practices that testers must utilize to increase efficiency and effectiveness. I chose this blog post because as we continue to learn different software testing strategies in class I think it was important to highlight some important aspects that could be utilized as a tester so we can make sure we incorporate these in the future. I thought that this blog highlighted good practices that were covered in class and even added some more.

The blog presented recommendations and strategies for effective unit testing, catering to developers aiming to streamline their testing workflows.The blog begins by explaining the significance of unit testing in software development, highlighting its role in detecting bugs early, ensuring code reliability, and facilitating code maintainability. It emphasizes the importance of adopting a systematic approach to unit testing to maximize its benefits. The blog advocated for writing clear, concise, and focused tests that target specific functionalities or units of code. Emphasizing readability and maintainability, the blog suggests using descriptive test names and organizing tests into logical groups. The blog also addresses the importance of test automation in modern software development. It advocates for automating unit tests to expedite the testing process and ensure consistent test coverage across code bases. By integrating automated tests into continuous integration pipelines, developers can detect regressions early and maintain code quality throughout the development lifecycle.In addition to automation, the blog stresses the significance of test isolation and dependency management in unit testing. Techniques such as, mocking and dependency injection are recommended to isolate units under test from external dependencies. The blog also touches upon strategies for handling test data effectively, including techniques like parameterized tests and test data factories. By managing test data efficiently, developers can enhance test coverage and minimize test redundancy.

After reading this blog post, I believe that I am now more confident and informed about how a software tester should go about testing strategies. Being able to know good testing practices will be beneficial so I can focus on utilizing the skills within my own work. I found it interesting how most of the practices that were being mentioned in the blog were very simple. This makes it even easier to understand and incorporate these rules as they will be easy to remember and become a standard foundation whenever I have to think about writing tests for a project. 

https://www.testim.io/blog/unit-testing-best-practices

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.

With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the team.

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