Several core contributors to the Jest testing framework present in a video entitled “Delightful JavaScript Testing with Jest“. (May 30, 2018) https://youtu.be/cAKYQpTC7MA

In one of the presentations “Writing Meaningful Tests”, a critically important part of testing is discussed by Facebooks’ Aaron Abramov. – TIME.

Dev production projects (including agile projects) always involve deadlines. Assuming the deadline is reasonable (though some are not), what happens if requirements are delivered late? or something unforeseen, like a temporary system failure occurs? Hopefully, the deadline can be pushed back, but for many reasons, that may not be possible. Especially under these circumstances, it is difficult to see how something like TDD (Test Driven Development) would be practical.

Imagine a dev lead explaining to his/her team: “We’ve got to get this project to staging by deadline x. Since we are now using TDD, for each file we create, we will also need to create a complete set of matching test files that contain meaningful unit tests, one for every function. When code updates are necessary during development, we’ll need to update the matching test file as well. When the unit tests are complete, we’ll need to create integration tests for a, b, c and d. Keep in mind, the deadline is x.”

In Aaron Abramov’s presentation, what was especially “delightful” was that, unlike many TDD evangelists, he directly addresses the issue of TIME. He references a chart comparing “Code Coverage” to “Time Spent Writing Tests”. More coverage, more time. He also discusses how developers usually have to write many bad tests before achieving a meaningful test. This suggests writing tests can be very time consuming. Tests that are slow, or often fail (even though the app runs problem free) are likely “bad” tests.

For complex apps, Aaron says “there is a point of diminishing returns”, meaning as the amount of code increases, it becomes more difficult and more time consuming to write meaningful tests. The advantages of writing more tests may not outweigh the cost. Aaron recommends considering the type of app you are working with and then planning what kind of testing is needed for that app. In some cases, like internal apps, few or no tests may be necessary. However, a more complex banking app would require much more time for writing tests. Obviously this would need to be reflected in the deadline.

Aaron and the other presenters make many other excellent points. If you work with testing, Delightful JavaScript Testing with Jest is well worth watching https://youtu.be/cAKYQpTC7MA. Although this presentation was made in 2018, the principles still apply. For developers facing hard deadlines, the term “Delightful” in the title is fitting.