|
|
|
|
|
by hutteman
5129 days ago
|
|
I think you're confusing unit tests with integration tests. In integration tests you should indeed run as close to real data as possible and execute your system's entire stack, including database calls. Unit tests on the other hand should be used to test small decoupled parts of the codebase. If you have a class that implements certain business logic against data that would normally be retrieved from a database, a unit test using mocks can test this business logic in isolation, feeding a variety of data through the method to test a large number of scenarios and edge cases. Speeding up this kind of testing is definitely important; test suites using mocks that can run in seconds can be executed after most changes to give immediate feedback to developers, whereas integration-type tests that might take an hour or more would slow down development too much to do this. Integration tests are important as well, and should be run possibly nightly or at least prior to any release. They cannot be used to give the kind of immediate feedback that truly decoupled unit tests give though. |
|