With UAT IT tests I frequently have some or all of the following types of tests: smoke (the page get at the endpoint loads), happy, sad, optional and audit.

How many of these test types does it make sense to apply to unit tests and which make sense to add? For example if I make sure the caller of a method doesn't pass a null and always passes an array, does it make sense to have unit sad tests for null, invalid, etc for what is passed. Should we have them now because that is possible in the future and we might not realize to add them then?

Currently I am thinking I have just happy and 1 sad test for unit tests. That would also be based though on small functions that do one thing. Wondering what advice others could give for unit test types?

  • I would go for 1 sad test case for unit tests, as you suggested.
    – Yu Zhang
    Commented Jul 6, 2018 at 2:51

2 Answers 2


Unit tests should ideally test every code path, because they are usually the simplest and by far the fastest way to test. You should be able to run at the very least thousands of unit tests for every single UAT you have. So if your code is at all testable it is very likely that adding a unit test for sad cases is a win.


No. The two are completely different in their nature and have different intent all together.

Unit tests only test the publicly facing APIs written in the development code. They are meant to be isolate and they give really quick feedback on the development status. Sometimes they can also be used for documentation purpose as well. These are mostly done by the developers.

UAT tests the application as a whole and mostly covers end to end scenarios and different product workflows. UAT tests tend to be slower as they try mimicking the end user. These are done by the product owner and end users.

There are lot to add, but the above couple are the primary ones.

  • Just an observation about "publicly facing APIs". That's not entirely true: One can dynamically change the access attributes of a method, function or class, thus enabling checking its behavior as an isolated unit. Commented Jul 6, 2018 at 13:09
  • My understanding was unit tests are coupled to public facing APIs. I want to understand the exceptional part. Could you please give an example so that I can understand better. Commented Jul 6, 2018 at 16:24
  • Let's say you have a public method which calls a private one, passing a randomly generated argument. This private method deals has three boundaries cases to test. If you cannot call the private in isolation, you cannot cover it properly. Another case would be if a command before the call to the private method raises an exception, no test would reach the private method - you would not be able to check it until the fix on the public one, diminishing the amount of information your execution can give at once. Commented Jul 6, 2018 at 16:42
  • This article shows how to use reflection in PHP for such a task jtreminio.com/2013/03/… This way, you can mock the private method for the checks of the public one, making them really isolated checks: Faster, more specific and clear. Commented Jul 6, 2018 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.