loading...

Introduction to TDD: What it is and why it is important

wolfdominion profile image Hannah ・2 min read

Many companies today are using test driven development or TDD to create their web software.

Why is test driven development so important?

TDD has become very popular because it prevents issues and bugs in the future, it can increase the efficiency of your work flow, and help teams communicate the intentions of their code's functionality. A downside of TDD is that it takes longer to get a project started, so it requires a little bit of up-front patience.

The basic flow of TDD

  1. Create a test (make sure it fails so you don't get a false positive)
  2. Write code to try to pass the test
  3. Once passing, refactor where possible in both test and implementation code
  4. Create the next test and repeat

Concepts to keep in mind while creating tests

Readable -> Make it clear what the test's actual and expected behavior is, and why.

Isolated -> Make sure tests only cover a particular segment of code, because you don't want certain tests interfering with other tests. If interference occurs, you may not know if the test failed due to your target code or from a previous test.

Thorough -> Prepare for edge cases, like if someone enters in something totally unrelated to the expected input. For example, what if someone tries to submit an empty form?

Explicit -> This ties in with code readability. If someone looks at the test, they should be able to require little setup.

The 3 main types of tests

Unit test -> small pieces of functionality

Integration test -> checking if all the smaller tests/code work together such as seeing if the app communicates with an API (Application programming interface) correctly

End-to-End -> tests entire application from user viewpoint (examples: Selenium or Cypress.io)

Getting Started

(usually in the form of libraries)

  1. Testing environment/test runner (the place to run tests)
  2. Testing framework (Ex. Mocha or Jasmine, organizes/holds your test code)
  3. An assertion library (this allows you to not have to write tons of if-statements, this does the actual verifications of test results)

Sources:
https://www.linkedin.com/learning/javascript-test-driven-development-es6

https://stackoverflow.com/questions/25678063/whats-the-difference-between-assertion-library-testing-framework-and-testing-e

Posted on by:

wolfdominion profile

Hannah

@wolfdominion

Silly errors I've solved, tech philosophy, and project journeys. Enjoy : )

Discussion

markdown guide
 

HI Hannah - there's a critical step between #2 and #3...

(1) Create a test (make sure it fails so you don't get a false positive)
(2) Write code to try to pass the test

(2.5) Refactor your test and/or implementation to remove duplication

(3) Once passing, create the next test and repeat

 

Hi Hannah,
Hi Andy,

Yes, I think "Refactor" should be an explicit step. Otherwise it is ignored too often.
I'm also not the biggest fan of the popular "Red - Green - Refactor" cycle. Mainly, because it is missing another important explicit step. Kent Beck originally wrote the following in his famous book:

  1. Add a little test
  2. Watch it fail
  3. Make a little change
  4. Run Tests and succeed
  5. Refactor to remove duplication

The second step is super important and I am happy that Hannah mentioned it in this post. Watching the test fail should be an explicit step in every TDD cycle as well.

 

I was thinking about the same thing, in the beginning i was coding with TDD i was always telling to myself the different steps (like in the image) i was like red, green, purple, red green, purple... my coworkers thought i was crazy (well they're not wrong xD) I like that sentence in your article "help teams communicate the intentions of their code's" it is true, sometimes i write a test for "documentary" purpose but don't forget refactoring can help your team to understand your code :)

overall nice article though :)

(image found on google: "test driven development circle" found it from the site lewandowski.io/2017/02/thre-levels...

Thanks for sharing the article, the image is very concise.
I can relate to the thinking of steps in colors, having an art background a lot of the way I code is very visual in my mind.

you're welcome ! :D I'm more a "talk-to-myself" kind of person and moving a lot in the office it .... can annoy some colleagues xD

 

This is interesting because I was debating about specifying about the "Red - Green - Refactor" in the article. However, I felt that it narrowed down the essence of TDD. If someone is new to the concept, I don't want them to think this is the main or 'only' way.

I really like the Kent Beck reference. Which book is this from? I'm interested in reading it.

It's from Test-Driven Development By Example.
The book is absolutely worth reading. And with its 240 pages, it is relatively short. :-)

 

I even used to push the failing test, to have the CI prove I have a test I can make run.

 

I'm so glad you added to this. It's definitely not just about getting the test to pass, but also making sure it is efficient.

 

That's so true... there is an inherent risk of narrow-focused thinking in TDD which can lead to a large number of small, locally optimised "ugly" solutions. I like an explicit "Refactor" step because it provides a mental reminder to developers that the internal quality of their solution is super important, so they should make time to focus on it each micro-iteration (i.e., Red -> Green).

 

In my last job, we wrote tests to existing code. One authority said then that is like foreplay after having sex. I wonder why he assumed developers know how to have sex, but now I know how to write tests.

 

Hahah, developers don't have time for that. We have to sit at the computer all day with our unromantic 'logic'

That's weird though, did a non-programming manager decide you all had to write tests for pre-existing code?

 

Exactly. We had a boss (a small company's CEO) who once heard a new term TDD and wanted us to implement it in our existing project because he thought it would help us deliver things faster 🤔 (it didn't)

 

thanks for sharing. the actual problem starts how to write those test efficiently since most of time it connects to DB.. so with mocking DB or other function/API response that is when the actual problem starts and developer loose zeal of writing proper test cases

 

You're welcome! You are right, the next step is to actually do the hard work- coding and coding it well. I am working on learning Jest testing right now, so hopefully I'll get some more technical how-to posts up in the next month or two.

 

I think you skipped the "why it is important" section.

 

I think Hannah did answer the question:

It prevents issues and bugs in the future, it can increase the efficiency of your work flow, and help teams communicate the intentions of their code's functionality.

 

I guess I missed it since it was so small and labeled "Why is test driven development so popular?" :)

Thanks for mentioning this, I updated the article to improve the readability!

 

A huge article, thanks to share with us your knowledge

 

You're welcome! I had no idea people would find it so useful, I was just trying to learn it myself haha