Quality != Test cases Count

Quality != Test cases Count
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):

  1. Test one thing and assert many
  2. You can’t test same kind of thing multiple times
  3. Every assertion such validate your test condition - don’t just code for success or fail [it will still be pretty useless]
  4. 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:

  1. A date in different formats
  2. A username as a sentence
  3. 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.

Would you like to get such bits of open test strategies in your inbox? Don't forget to subscribe here.

Subscribe to Haox

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe