When writing a unit tests. There are couple of things to do and couple of things which should be avoided. In this article I have listed the dos and don'ts with regards to unit testing.
dos
- Test only the public functions.
- Test each and every public function. In a ideal world a class should have only one public function and its dependencies.
- Mock every dependency.
- Test should cover success and failure, both aspects of a code.
- Test that every raised exception is tested.
- Always specify how many times a function is expected to be called while testing a piece of code.
- Test setup pain is a smell, which means your code needs to be refactored.
- Code coverage should be 100%, which means each and every line of the tested class was reached.
- Live deployment should not work with failing unit tests.
- Add tests to classes which are missing unit tests.
- Write meaningful names which explain what the test is doing example names testUserRegistrationWasSuccessful, testUserRegistrationWasNotSuccessful, testUserRegistrationRepositoryThrowsException
don'ts
- Tested class should never talk to database, file, network resources etc.
- Dependencies in tested class should not create real class objects.
http://www.rosenborgsolutions.com/articles/phpunit/phpunit-best-practice
Top comments (6)
These are good points. Thanks for summing them up! 💪
Except the first one, "Test only public methods", any reasoning behind it?
Private methods are normally called from within a public method. So they will always be tested when you write tests for your public methods.
If that is not the case it means, the private method is not being used and should be removed from the class.
Yes, that's correct. I found myself however, that testing private and protected methods does make sense in certain cases.
Imagine a complex public method that abstracts part of its logic into private methods. Testing these, if there is an error, you will probably identify it easier if the error also shows in the tiny private method.
Furthermore, if you are building your class/app logic from bottom up using TDD (test driven dev), you will most probably encounter cases where you write tests for methods that you design as private.
Otherwise, I fully agree that if something is not used, it should be refactored.
I am fine with testing private functions altough I never had any problems with just testing the public functions and I am doing that for past 4 years.
Your point which says "Imagine a complex public method that abstracts part of its logic into private methods."
I personally try to follow the Rules of Object Calisthenics (gist.github.com/bobuss/6534934), one of which says that Keep all classes less than 50 lines. With small classes it is really easy to see which scenerios need to be tested. If the tiny private method throws an Exception. It will also be thrown in the public function which is going to call that tiny private function, and from there it can be easily tested.
This is my personal opinion, I am just happy to see tests in any code :-)
What should be your reference to generate unit test cases? Should you look at the code and do it? Or should it be from design or requirements (atomic)?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.