Future Investment with Test-Driven Development

Although TDD requires hard-work in the beginning, it will definitely benefit your future development

“Making a test before even writing a single line of actual code? Are you serious?”, I said on my first day of web design class. It was infuriating at first, trying to create a test for an imaginary program that is assumed to be working.

However, after experiencing collateral damage because of not doing TDD, I can say confidently that doing Test-Driven Development has its benefit for the continuous development of your program. Why? Because if you don’t have any test and find bugs in your program, it will be difficult to track where did you go wrong. Some developers even said, “Sometimes, it is more efficient to write an entirely new program than searching bugs in an untested program”.

To ensure that you guys will not make the same mistake that I’ve done, I try to explain a little bit about Test-Driven Development, the benefits of using it, TDD’s best practices, and an example of implementing with Flutter.

First of all, let’s look at how Test-Driven Development Works:

“Test-driven development is a software development process that creates software in very short iterations with a minimal upfront design.” — Janzen, D., & Saiedian, H. (2005).

Test-Driven Development starts with thoughts on how to test the required functionality. After writing automated test cases that generally will not even compile, you should write the implementation code to pass these test cases. The work is kept within the programmer’s intellectual control; as the programmer is continuously making small implementation decisions and increasing functionality at a relatively consistent rate.

All of the test cases that exist for the entire program must successfully pass before new code is considered fully implemented. Hence it is perceived, with a degree of confidence, that the new code will not introduce a fault or mask a fault in the current codebase.

Another thumb rule in TDD is that whenever a software defect is found, unit test cases are added to the test suite before fixing the code.

An important rule in TDD is: “If you can’t write a test for what you are about to code, then you should not even be thinking about coding ”

Benefits of Test-Driven Development:

According to George, B., & Williams, L. (2004), these are the benefits of implementing Test Driven Development:

Program Comprehension: According to T.A. Corbi (1989), half of the programmers’ task during software maintenance is involved in understanding the code. TDD approach will make the program becomes more comprehensive by encouraging the programmers to explain their code using test cases and code itself, rather than by using descriptive words. TDD will also ensure that the test cases are up to date. Efficiency: TDD researches believe that the fine granularity of the test-then-code cycle gives continuous feedback to the programmer. With TDD, faults are identified quickly as new code is added to the system; hence the source of the problem is more easily determined Test Assets: TDD enables testability. The use of the TDD practice drives programmers to write automatically testable code such as having functions/methods returning a value that can be checked against expected results. The automated unit test cases written with TDD are valuable assets to the project. Reducing Defect Injection: D. Hamlet, J. Maybee (2001), assert that debugging and software maintenance are often perceived as a low-cost activity in which a working code defect is patched to alter its properties, and specifications and designs are neither examined nor updated.

Test-Driven Development Best Practices:

According to my Software Development Class’ guidance paper, these are the rules that one has to follow when using TDD method:

Test First: Always make the test first before starting the development of the program. Remember the Red-Green-Refactor principle Acceptance Criteria: All the tests refer to the Acceptance criteria written in the user story. Online Repository: All the development has to be posted in an online repository. Commit Milestone [RED]: The development has to be started with the test without the implementation. Clean test: Always remember the FIRST principles! (Fast, Isolated/Independent, Repeatable, Self-validating, Thorough/Timely). Commit Milestone [GREEN]: When the test has passed, push the code to the repository Code Coverage: Have to be 100%, meaning all your code has to be tested thoroughly without leaving any single line untested.

Implementing Test-Driven Development on Flutter:

This is an example of a simple program that makes a text field using Flutter. If you’re curious about the result of these codes, you can scroll down and find the result’s screenshot there.

First, create the main.dart file if you haven’t set it up! At least it should be like this

Then, for example, you want to make a text form field. Try to make an empty class textForm.dart :

We do not have to implement the class right away. Instead, let’s make some test for determining what kind of output do we want to get? For example, we want to know if we have one text form field widget and a ‘Name’ text above it.

We could implement it in a file called textFormTest.dart . Do not forget to import your file!

You can run the test now and get the result that your test has failed. Awesome!

Now let’s create the implementation for the class textForm.dart !

Now finally, you can run the test file at the textFormTest.dart file and the test is supposed to return with a pass result now!

If you compile the main.dart file , it should look like this:

Screenshot of the main.dart file

Now that you’ve already known a little bit about Test-Driven Development, let’s give it a try. Doing test-driven development from an early stage of software development will certainly benefit you in the future.

References:

George, B., & Williams, L. (2004). A structured experiment of test-driven development. Information and Software Technology, 46(5), 337–342. Janzen, D., & Saiedian, H. (2005). Test-driven development concepts, taxonomy, and future direction. Computer, 38(9), 43–50. Kaufmann, R., & Janzen, D. S. (2003). Implications of Test-Driven Development: A Test Study. In Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (p. 298).

Follow us on Twitter 🐦 and Facebook 👥 and join our Facebook Group 💬.

To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇