Self validating tests
In any application, which solves real world problems, having problems in it’s unit tests – is least desirable thing.
Good written tests are assets while badly written tests are burden to your application.
Let’s learn about these FIRST principles – in detail.
Unit tests should be fast otherwise they will slow down your development/deployment time and will take longer time to pass or fail.
Typically on a sufficient large system, there will be few thousand unit tests – let’s say 2000 unit tests.
If average unit test take 200 milliseconds to run (which shall be considered fast), then it will take 6.5 minutes to run complete suite.6.5 minutes doesn’t seem long at this stage, but imagine if you run them on your development machine multiple times a day which will eat up your good amount of productive time.
And imagine when the count of these tests increase when new functionalities are added to application, it will further increase the test execution time.
The value of your suite of unit tests diminishes as their ability to provide continual, comprehensive, and fast feedback about the health of your system also diminishes.One of the major cause of slow tests – is dependency that must handle external evil necessities such as databases, files, and network calls. So to make suite fast, you must avoid creating these dependencies by using mock testing.Never ever write tests which depend on other test cases.No matter how carefully you design them, there will always be possibilities of false alarms.To make situation worse, you may end up spending more time in figuring out which test in the chain has caused the failure.In best case scenario, you should be able to run any one test at any time, in any order.By making independent tests, it’s easy to keep your tests focused only on a small amount of behavior.When this test fail, you know exactly what has gone wrong and where. The Single Responsibility Principle (SRP) of SOLID Class-Design Principles says that classes should be small and single-purpose. If one of your test methods can break for more than one reason, consider splitting it into separate tests.A repeatable test is one that produces the same results each time you run it. On occasion, you’ll need to interact directly with an external environmental influence such as a database.To accomplish repeatable tests, you must isolate them from anything in the external environment not under your direct control. You’ll want to set up a private sandbox to avoid conflicts with other developers whose tests concurrently alter the database.In this situation, you may use in-memory databases.