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
- Create a test (make sure it fails so you don't get a false positive)
- Write code to try to pass the test
- Once passing, refactor where possible in both test and implementation code
- 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)
- Testing environment/test runner (the place to run tests)
- Testing framework (Ex. Mocha or Jasmine, organizes/holds your test code)
- 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
Oldest comments (19)
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
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:
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!
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)
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:
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.