-
Notifications
You must be signed in to change notification settings - Fork 1
testing general information
(work in progress)
Tests are done one per method functionality, all the failures should be precisely pointed out during the execution (i.e. by means of asserts).
Tests should be named in such a way, that describes the assumption or requirement which is under test. It should be as precise as possible.
Wrong names:
get_[property_name][function_name]_works_properly
Valid names:
constructor_throws_on_inconsistent_input_sizes[function_name]_throws_on_null_[parameter_name][class_name]_initializes_for_valid_inputsminimum_of_empty_collection_is_zero
Everybody who writes an implementation of some functionality is obliged to write tests to it. Everybody who modifies existing, tested implementation is obliged to make sure its tests still pass.
Tests should span as many different use conditions as possible, such as boundary conditions, invalid input, etc. We target maximal coverage.
- Code without or with incomplete tests will not pass the code review process.
- Code that does not pass all the tests will not pass the code review process.
The tests should be created in separate tests project and all the internal structure should mirror the original project's one.
After every larger code addition (milestone?) that implements functionality provided for the end user, appointed people will be testing the software by simulating typical and non-typical user behaviour according to pre-defined case scenarios. The goal is to trace as many software bugs as possible before introducing new iteration of the codebase. Every found problem should be reported as new issue on GitHub.
Every single bug should be reported as a separate issue on GitHub along with following information:
- Title: [ComponentName] Brief one-liner describing the issue.
- More detailed description of the problem.
- What case scenario has been violated by the bug.
- Steps to reproduce.
- (Optional) Visual representation of the bug - screenshots, etc.
Bugs from the issue list are assigned to programmers. Afterwards, a new branch in the repository is created, where assigned programmer works on the solution for that single issue. After the solution is found, the code goes through the code review process and if it passes it, it is pulled to the main branch and the issue is set as resolved.