Unit testing is a very debatable subject. Is unit testing necessary ? Is the extra time needed to implement unit testing in a project really paying off in the end ? Well... let's see; one of the developers in Qubiz will tell us his perspective on unit testing.
Unit testing is the way through which a developer checks if the logic of his code behaves as it is intended to. For each piece of code a developer wants to test, he will write a test method.
Every project needs a documentation, so that the stakeholder for that project can learn how the project works, unit testing is the project's documentation for developers. It also allows the developer to execute the code right away and see if the expected result is returned. If a project's unit is re-written it is easy to find out if the new code still returns a correct result.
When a developer thinks about the result a unit test should return on the piece of code it was written for, he inevitably thinks about the exception flows as well. In the case of API's, if you write the unit tests first, the API will work the way you want it, so unit testing also helps you to get a better design.
Basically the main reason for using unit testing is the fact that you can stay assured that the unit is working the way you expect it to do.
The quick answer to this question is always, you should always use unit testing in your projects. Unfortunately this is easier to be said than to be done, but on the other hand, realizing you need unit tests at a later stage in the project can make the implementation difficult, maybe next to impossible.
There are two basic things one should know about unit testing
The second point above raises an interesting issue, most projects need to be finished as soon as possible, so some developers could think of jumping over the unit testing phase. This could be a wrong choice, because if you write unit testable code and the unit tests associated with it, you might even finish faster. How so ?
There is no secret to writing unit tests, there are only some basic principles that one should follow so that it takes the full advantages of the unit tests instead of the getting stuck with them. The hard part is to write unit testable code, so that no dependency between the unit and the outside environment is unbreakable.
There are many articles on how to write unit testable code, here is a nice video about it:https://www.youtube.com/watch?v=wEhu57pih5w
To make your unit tests more readable you should use the AAA pattern; AAA comes from:
Unit test method names should tell you exacly what it's testing, I use the following pattern:MethodName_StateUnderTest_ExpectedBehaviorexample: Sum_NegativeNumberAs1stParam_ExceptionThrownMore about naming on: https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html
Unit tests should not be dependend on each other and they should not influence other tests. Make unit tests as simple as possible.Stay DRY(don't repeat yourself). It's best if you write unit tests for you're own code. If that is true, the most important part is to write unit testable code.
After you have some experience with unit testing you should start writing the test first and code after, you might want to search on Google for BDD and TDD for more details.
You can take a look at the following website: https://artofunittesting.com/ .
Then there is a video worth watching https://osherove.com/videos/2009/8/25/unit-testing-best-practices.html.
There is also a great book on the art of unit testing: https://www.amazon.com/exec/obidos/ASIN/1933988274/iserializable-20
and an article that approaches the issue from the avoid-untestable-code perspective https://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/