Unit Tests are the heart, the center of Agile testing and development projects. No wonder much is already written about them. You may find lots of different tricks and how-to’s all over the internet. Some of them will work for you in your current project, some will be useless due you are using a different programing language.
How to UT?
Is there existing knowledge that may assist you anytime anywhere? Sure! Here are several tips you may find useful throughout your entire career despite the projects you will be working on:
- Which tests should I write first? Many testers just love to write sets of functional tests when the proper step to begin with would be directing every test towards one single product component. Some large and crucial components will demand suits of unit tests if not more.
- In most cases time is valued more than gold and you require testing enormous amounts of code within poor amounts of time. Long tests or ineffective checks are killing you literally. Don’t bite more than you can chew. Simple, light tests that are focused on the product’s core behavior are just what the doctor ordered. In the best scenario you will be using as little code as possible.
- Every environment requires to be set up from scratch. If you don’t want your tests failing one after another due they have used some earlier test environment components, that is. Though you may get lucky enough to have one environment required for all tests. A static setup block should do the trick in such rare cases.
- You won’t avoid mocking object, don’t even bother trying. This is something testers need to deal with. Tests that are running against your system in production tend to be too dangerous. Though interfaces may be mocked with stubs thus required data is simulated.
- Make sure you are aware how your unit tests are named. Every single one of them. You have done all well if the name accurately describes the test’s scenario, result and subject. You can neglect this step of course, but be warned: maintenance will be a pain in your… neck.