Lean Approach

Quality != Test cases Count

Hanisha Arora

Aug 29, 2023 — 2 min read

Photo by ThisisEngineering RAEng / Unsplash

Choose one - 60 test case or 10 for one function?

General Opinion:

More the test cases, better the code. So, 50.

Alternate Opinion:

If you choose 50,

Season 3 Ugh GIF by Parks and Recreation

It’s better don’t spend time on writing test cases, just do the development rather - it would be less waste of resources.

Why? Because 90% of the test cases here are completely useless.

If you're following TDD in your project or doing testing but it's not helping you to do this,

Improved models - Think about your models first.
Faster implementations - use short cycles to give you feedback more often.
No obvious, workflow bug - enables you to get a different perspective on your code.
No test case fail - see your tests as ”living specifications” rather than after-the-fact tests.
Debug fast

You need a new plan, your testing pipeline is completely faulty. You really need to question - Do you know testing?

So, The main point - How to know what testcases are required to add?

At GreyB, a simple rule list - your test case should fulfil the following rules (this is what even uncle Bob says):

Test one thing and assert many
You can’t test same kind of thing multiple times
Every assertion such validate your test condition - don’t just code for success or fail [it will still be pretty useless]
It should be something that can happen in production

Let’s take an example:

I have to write test case for a function with input - Name, Date

Possible Scenarios are:

	Case	Comment
1	Alphanumeric Username, date	Valid Testcase
2	Numeric Username, date	You already tested in #1
3	Alphabets Username, date	You already tested in #1
4	Valid Username, valid Date	You already tested in #1
5	Valid Username, invalid date	Valid Case
6	Publication, invalid hacking script date	Would someone really do this? If you are thinking to create a testcase for this. Please check how you are handling validations. That part needs to work on. This should be handled by the framework and not bothered by testings.
7	Null Username, Null Date	Valid Case
8	Missing one of the field	Valid Case
9	Null Username, Valid Date	You already tested in #7
10	Long Username, Valid publication	Valid Case
11	1 letter Username, Valid Date	Please bother your validators for this. This should not be tested
12	Out of human’s limit max length Username or date	Please bother your validators for this. This should not be tested

And there can be hell lot more of them. From the comments if you see, the useful test cases have reduced to half.

Now what are actually useful test cases other than these 5:

A date in different formats
A username as a sentence
Different kinds of characters in username

This makes it useful 8 test case that really works for the functionality. Now these things are context based and would test for what a user can actually do. Otherwise, there is finer testcase than what a user will perform.

Your tests should help you to test multiple things in least number of ways otherwise testing will never end and myths like 100% test coverage becomes true.