Different Types of Unit Test Strategy

I witness some ways of doing unit tests during my career.

I learned all of those from learning a new language and then finding the unit test framework people typically use. Various frameworks teach us different ways of making unit test, they even teach us the philosophy of unit tests.

It might not be a complete reference of various unit test strategies existing in this world, so if I missed some important thing, please let me know then I can make an update for the next persons coming.

Problem With Testing

Before moving to the point, I would like to brief you this simple problem of how to create a unit test for the very smallest part of your code.

Sometimes, we didn't have much choice when the existing code has been equipped with a unit test. As a n-th person working toward the code, your job is to make that unit test all green withstanding your very current changes. Some changes on the unit test may be required, or you may need to add new cases to an existing one.

When there is no existing unit test or you make radical changes to the code, you will mostly need to think about how to write the unit test. You want it to be simple enough to write, yet convincing enough to withstand future unlimited alteration.

Behaviour Driven

This one is by far the easiest to understand because it is so intuitive to think about. To put it simply, our flow must behave somewhat according to what we desire. To work with this strategy, you may need to write down some cases with preconditions, actions, and a set of expectations.

It is easier for other developers to read. Most unit testing frameworks that go with this strategy require us to write a simple and meaningful comment.

Most of the frameworks using this strategy also uses Gherkin notation, it is even very convenient if you are serious about assuring your code through the unit test.

Test Coverage Driven

The unit test may be not on your agenda so far. At then end, you still need to convince everyone that you have a set of unit tests to withstand future changes. So far, I believe this strategy is the easiest one to encourage people to write it because it has a clear quantitative measure.

I don't prefer this strategy of writing unit test. It encourages you to leave something when you may haven't. Since you have written a unit test that went through these lines, there is no point to add another going through these.

Let's be honest, we prefer to use this strategy because we can show this to our manager right?

Test Table

Test table comes in very handy, sometime you don't need any testing framework to write one. For newbies, coming up with the idea of writing a test table is surprising. I even hadn't seen that until someone wrote a test table on our code base.

Other than behaviour-driven, the test table is also my favourite when you have a very simple unit to test. For me, it could be a tiny function that branched out to improve the readability of the main flow. We can then bombard this small function with tons of cases.

What's next?

I also wondered up to this point, what would you need to know after knowing all of this? For me, I would like to know a real example of unit test, some parts of me wants to know the step by step of planning to write a unit test.

Let me know if you want to know something.