Testing: Difference between revisions
Adamcolton (talk | contribs) Created page with "== Unit Tests == Can access private data. Should not access external resources. Should hit any branches the API tests do not hit. == API Tests == Cannot access private data d..." |
Adamcolton (talk | contribs) No edit summary |
||
| Line 15: | Line 15: | ||
== Test Dependencies == | == Test Dependencies == | ||
Unit and API tests can declare dependencies. Like Lapiz. If tests start failing, it prevents a whole bunch of tests from failing because something low level is broken. | Unit and API tests can declare dependencies. Like Lapiz. If tests start failing, it prevents a whole bunch of tests from failing because something low level is broken. | ||
== In Code? == | |||
Should tests be allowed in code or restricted to test files? | |||
An argument for allowing them in place is that you can use the tests as documentation for code right alongside the code. | |||
Latest revision as of 20:11, 28 September 2019
Unit Tests
Can access private data. Should not access external resources. Should hit any branches the API tests do not hit.
API Tests
Cannot access private data directly. Consider allowing including test hooks. Should hit every public portion of the package. Should try to get to 100% coverage, though this may not always be possible.
It may be worth having AssertInaccessible checks that will return data if the program gets into an unexpected state, but failure to hit them does not count against the 100% test coverage.
Integration Tests
Can access resources.
Application Tests
Runs the application with specific input and checks for specific output.
Test Dependencies
Unit and API tests can declare dependencies. Like Lapiz. If tests start failing, it prevents a whole bunch of tests from failing because something low level is broken.
In Code?
Should tests be allowed in code or restricted to test files?
An argument for allowing them in place is that you can use the tests as documentation for code right alongside the code.