unit_tests

How Does a Perfect Unit Test Look Like?

The title got your attentions? Well, then it did what it had to so please stop hitting me with various objects and are you sure a gentlemen is to use such language as you just did? I am well aware there are no things in software testing that may be considered ‘perfect’ but that does not mean we can’t try, right? So here are some things some top quality unit tests are to look like by my humble opinion.

Arnold

A great unit test is to be Atomic!

A great unit test is (as all American) an independent unit test that is not relying on environments or other tests or the order by which it is executed. If you, for undeterminable reasons, have decided to run one test for ten billion times its result is to be the same each time. Thus using things as static variables and external data may cause leaks, thus be warned.

A great unit test is testing the What rather than the How!

Unit tests are usually written by people who are responsible for the code under test and it gets hard for them not to test how the feature is implemented and this may and, more likely will cause tests to fail as implementation usually changes a lot. Many other issues may take place when internal objectives or methods are under test as they were never meant to be seen somewhere outside the class thus there has to be a fairly serious reason to you testing such things.

Stay off schedule

Bu scheduling I mean, as noted before, unit tests are to lead to same results regardless of outer factors. Meaning usage of objects related to multithreading such as timers are not to be used in tests or, if there is no other choice they are to be dealt with carefully so tests are not failing due scheduling. Also consider avoiding testing operations that are related on time like Sleep, etc. as tests may simply fail due high CPU utilization.

Stick with precise data

Many developers tend to various random data or numbers they are placing inside their unit tests. What may this lead to? Two things only: a) there will be uncertainty in the tests and b) after tests are failing their reproduction is close to impossible as data does tend to change every time a test is running.

More is never better. It is usually more complex and that’s it…

Sure it is a nice habit to test every single aspect of whatever you are having under test, but gathering several tests into one thing is simply adding unnecessary complications into the process and Unit Tests are not even nearly as solid as they should be. Testing one thing at a time is much more reliable and easier to locate and document if one of the tests is failing. After all, that was the original point of unit tests, right? That’s is the right way for proper application testing.


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Images are for demo purposes only and are properties of their respective owners.
Old Paper by ThunderThemes.net © 2017

×