Skip to content
loading...

Tests !!! Please !!!

brandelune profile image エラリー ジャンクリストフ twitter logo github logo ・1 min read

Following up on the "IT education sucks" post, and especially on my comment "no CS/CL book I've had had a chapter on writing tests" (or suchlike), I'm hereby officially asking for a tutorial, or pointers on tests :)

  • how to write a test
  • what to expect from a test
  • how to test that a test properly tests

and anything else that you think matters, in likeimfive terms...

twitter logo DISCUSS (6)
Discussion
markdown guide
 

This is a big topic but there are a few resources that standout for beginners:

  • Unit Testing: Basics and Best Practices - Erik Dietrich (blog post) MUST READ - START HERE
  • Starting to Unit Test: Not as Hard as You Think - Erik Dietrich (book)
  • Working Effectively with Unit Tests - Jay Fields (book)
  • Working Effectively with Legacy Code - Michael Feathers (book)
  • Test-driven Development - Kent Beck (book)
  • TDD Chess - Erik Dietrich (YouTube)
  • Unit testing courses on PluralSight (videos)

It can be intimidating when you are first learning to test. Start slow and only test the easy stuff at first (functions with no side effects are easiest). Then learn to test the harder stuff (like legacy code). And top it off with TDD eventually.

Happy testing!

 
 

"how to write a test"
First option: New feature added? Write a test for it to ensure feature works as intended.
Second option: New feature wanted? Write a test as if the feature is already there. And keep coding until the test passes.
"what to expect from a test"
The dumb answer is "that it passes!". Tests also should be very reliable and low-level as much as possible. This means they should employ as little abstraction and helpers as possible.
"how to test that a test properly tests"
If you are not sure if some test properly tests, see the previous point, that is, make it reliable and very simple. If still in doubt, write an additional test that does something opposite/invalid and assert it throws() an error.

P.S. I personally do not separate feature tests from unit tests because I don't like to decide which are which. They are all feature tests to me.

P.P.S. Follow me here or on twitter, I am currently finishing a nice all-in-one and innovative testing tool. It has a built-in coverage reporting so you don't have to learn things like nyc, istanbul, etc. as well. But the coolest thing, it is intelligent and suggests HOW and WHERE a problem can be fixed (for the test to pass). Do not believe me? We'll see it when I release it in a few (not very few) weeks.

P.P.P.S. Sorry I guess I have little experience on communicating with 5yo kids.

 

You answered why write a test. Which I do understand.

My questions refer to, well, what I am supposed to test. A given output ? Based on a given input? How do I know that I cover all the possible inputs? And how do I know that the test output is correct? How different the test code is from the tested code?

You talk about "feature tests" and "unit tests". What are they? Do you have pointers?

 

What you are looking for in a test depends on the context of what you are testing, do keep that in mind, however here are a couple thoughts:

If you are testing something relatively small, say, a function, where it is realistic for you to test it's output, based on given inputs, then do so, an example might be:

  • Given a purchase of 19.99 and a VAT rate of 20%, do I return the correct price? What happens when the price/VAT change?

When you are testing something more complex than this, maybe because a lot of function callsare involved (an example might be an API endpoint, or a complicated routine), then you want to test for behaviour instead.

Example:

  • My endpoint received incorrect data: did I respond with 422 Unprocessable Entity?

  • My endpoint received valid data: did I save it correctly, did I answer with the right status code?

A good unit test should break if you change the code it is testing in ways that do not fit the previous assertions.

However, the overall behaviour or your program may not have changed, and therefore, these test may not fail at that point. This is ok. When you come to the point where you introduce new code, which breaks the desired program behaviour, they will, and you will be able to figure it out early on.

As such, unit tests are useful in the immediate, behaviour tests are useful on a longer timeframe, a healthy mix of both is generally where you want to be.

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

エラリー ジャンクリストフ profile image
In Japan since '97. Translating and localizing on Mac since 2000. FOSS advocate and user. Super proud that I have some code that's been accepted in Emacs :^)