Category Archives: Test-Driven Development

A Look at Test-Driven Development & Benefits

Since just before Spring Break, in CS443 – Software Quality Assurance and Testing we have transitioned on from boundary/equivalence class analysis and onto Test-Driven Development as a strategy as well as implementation. For me, this is a huge relief and joy to get back to working on actual code rather than theoretical comp. sci. work, though it also helped me recognize the importance of non-coding exercises. 

I’ve also been really enjoying TDD as I find it aligns with my general coding habits and builds off them to help me identify new coding practices and strategies for addressing challenges. So I decided to look at some blog posts discussing it and how it’s impacted software projects versus other methods used. Test Driven Development Is the Best Thing to Happen to Software Design instantly jumped out to me.

The post discusses the significant influence of Test Driven Development (TDD) on software design. It explains TDD as an iterative approach shaping an idea into implementation through a cyclical process of ‘fail-pass-refactor’. The author illustrates the two approaches to writing code and tests: one driven by code and the other driven by tests, emphasizing the benefits of TDD in terms of mindset and code quality.

This post also considers TDD in real-world scenarios, highlighting its capacity to provide fast strategic approaches to software challenges that may seem to have no place to start (by creating tests). It addresses challenges in testing and offers solutions such as spying or mocking, managing variable test data, avoiding bloated setup, and preventing “Mocking Hell.”

Additionally, the post discusses the tendency to add unnecessary features in code and how TDD, by its nature, prevents such occurrences, thus aligning with the principle of “You Ain’t Gonna Need it” (YAGNI). This is definitely a fault that I fall victim to at times as I try to plan ahead too far in a project and add unnecessary code so I appreciate strategies to address it. Finally, it suggests that TDD not only aids in requirements meeting implementation but also serves as a technique for gathering feedback about software design, thereby advocating for Test Driven Design (TDD).

My typical strategy for developing code begins with creating a skeleton of basic components I expect to be easy to implement and then fill out the boundaries and remainders by developing minor unit tests (like print lines) to make sure it is working as intended. I sometimes do them at the same time, but I have been doing TDD sometimes without knowing it and am now better prepared to hone in on its benefits.

Source:

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

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Test Driven Development: Formal Trial-and-Error

Test Driven Development (TDD), like many concepts in
Computer Science, is very familiar to even newer programming students but they
lack the vocabulary to formally describe it. However, in this instance they
could probably informally name it: trail-and-error. Yes, very much like the
social sciences, computer science academics love giving existing concepts fancy
names. If we were to humor them, they would describe it in five-ish steps:

  1. Add
    test
  2. Run
    tests, check for failures
  3. Change
    code to address failures/Add another test
  4. Run
    tests again, refactor code
  5. Repeat

The TDD process comes
with some assumptions as well, one being that you are not building the system
to test while writing tests, these tests are for functionally complete
projects. As well, this technique is used to verify that code achieves some
valid outcome outlined for it, with a successful test being one that fails,
rather than “successful” tests that reveal an error as in traditional testing.
Related as well to our most recent classwork, TDD should achieve complete
coverage by testing every single line of code – which in the parlance of said
classwork would be complete node and edge coverage.

Additionally, TDD has
different levels, two to be more precise: Acceptance TDD and Developer TDD. The
first, ATDD, involves creating a test to fulfill the specifications of the
program and correcting the program as necessary to allow it to pass this test.
This testing is also known as Behavioral Driven Development. The latter, DTDD, is
usually referred to as just TDD and involves writing tests and then code to
pass them to, as mentioned before, to test functionality of all aspects of a
program.

As it relates to our coursework, the second assignment involved writing tests to test functionality based on the project specifications. While we did not modify the given program code, at least very little, we used the iterative process of writing and re-writing tests in order to verify the correct functioning of whatever method or feature we were hoping to test. In this way, the concept is very simple, though it remains to be seen if it stays that way given different code to test.

Sources:

Guru99 – Test-Driven Development

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.