This shows you the differences between two versions of the page.
— | blog:2022:07:10:2022-07-10_-_automatic_test_groups [2022/07/10 18:40] (current) – created basz | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== 2022-07-10 - automatic test groups ====== | ||
+ | we all do automated tests. there are however a lot of differences in how test binaries are organized in the project. some of the patterns i've seen in the past are: | ||
+ | |||
+ | * unit tests, module tests and integration tests are kept in 3 separate binaries. | ||
+ | * there is a " | ||
+ | * there are separate UTs, MTs and ITs binaries for each module. | ||
+ | * there are multiple separate binaries with tests of each element of module(s). | ||
+ | |||
+ | split into UTs, MTs and ITs is very common. after all this is how we split tests in [[wp> | ||
+ | |||
+ | * fast (running) tests | ||
+ | * slow (running) tests | ||
+ | |||
+ | to make things elastic and well encapsulated, | ||
+ | |||
+ | this leaves us with final test group -- manual test binaries. these are binaries, that cannot be easily automated. eg. tests that need special HW components connected (like physical port I/O, to talk to 3rd party module), or output processing is not easy to automate, yet easy to verify visually (eg. edge detection on a real-life image). i've talked a bit more about these during my [[https:// | ||
+ | |||
+ | to put it a bit more into [[wp> | ||
+ | |||
+ | * fast (running) tests -- '' | ||
+ | * slow (running) tests -- '' | ||
+ | * manual tests -- '' | ||
+ | |||
+ | so now for each module i get 1 or more binaries: fast tests, slow tests and some number of manual tests (each binary helps to tests a single feature). for the typical code, we should be done with just "fast tests" | ||
+ | |||
+ | now running tests is simple and practical. daily, during development, |