Regularity: Run tests regularly, ideally before every commit, for optimal quality assurance. In particular, run all relevant tests before pushing code or creating a pull/merge request. Continuous integration practices are helpful for enforcing testing of code uploaded by other developers.
Use functional programming for data processing tasks because it is less prone to errors and side effects.
It's common to create test users and test data to facilitate the testing process.
Don't reinvent the wheel and use existing test libraries. There are proven solutions that minimize the effort of creating tests.
Use a common test structure convention by dividing the test logic into three parts
given (a context → setting up data, fields, and objects)
when (something happens → execute production code)
then (a certain outcome is expected → check the result via assertions)
Alternative common names for the three steps: arrange, act, assert
Use additional simple high-level checks. Use additional simple high-level checks. For example, when working with a collection, checking the number of elements is a good indicator of unexpected or missing elements.
More is better. When in doubt, it is better to write one test too many than one test too few. Possible duplication is a lesser evil than not testing at all.
Also test non-functional aspects such as security, single request computation performance, and perform load/stress testing to validate software throughput.
Keep test resources close to the tests to make their use easy to understand. Test resources should be placed in the same location as the test if the resource is only needed by that test.
Avoid threads if possible, as they are usually buggy and very difficult to test and debug properly. If threads are necessary, keep the amount of asynchronous code to a minimum. Also, separate synchronous and asynchronous logic to test them separately. Prefer thread termination conditions over fixed wait times, as this usually increases test performance dramatically.
