How do unit tests and integration tests actually run?

Question

There are plenty of resources that explain what unit and integration testing are and why they are important. That is not what I am asking here.

I am trying to understand how unit/integration tests are run and how they work.

I have a very tenuous grasp of how these tests work behind the scenes and I'd like some help in understanding them. I'm not asking about the inner workings of specific testing frameworks but what happens with the code when you decide to run a test.

Based on my understanding:

Unit tests

You have a function Foo() and in a separate class, you write a test for Foo() called TestFoo(). You decide to run your test using some framework. When running the test, the framework spins up a running version of your code and a fake mock database and uses the test inputs given in TestFoo to call Foo. Any dependency injected code is mocked away via the test and given dummy values as well. Once the function Foo() is done executing, we assert that the results are as expected.

Integration tests

You have a test that covers multiple units of the system including hitting a dev database. You run the test which spins up a running platform, calls Foo() and queries the return values and/or database for the appropriate changes.

As you can tell, it's a very handwavy explanation. I'd like to some help to flesh out my understanding of how the tests are run, how mocks are set up and how the tests manage to call functions with mock/live components.

Answer 1

Tests are just programs that run test cases. Some test frameworks have a separate test runner that can discover and execute all test cases. How that works depends a lot on the programming language. Sometimes the test runner is integrated in an IDE.

Integration tests are more likely to be standalone programs that runs the System Under Test. Often, integration tests are scripts that set up the test environment and then launch the software being tested. On one project I'm working on, there is a large corpus of integration tests. Each test has its own directory with data and extra software, plus a script that controls how the test is compiled and executed. The test runner is little more than a loop through all the directories to launch the test script.

Unit tests don't necessarily involve dependency injection. The unit test should test some unit in isolation, which means that the unit should not involve external dependencies. However, some software is already designed in a way that this is easy to do. It is also not mandatory to isolate the unit – it can be perfectly fine to keep hardcoded dependencies, especially if those dependencies have no side effects.

It's also useful to note that tests do not have to be automated — you can theoretically run unit tests in a debugger or a REPL, and run integration tests by hand. Of course, scripting the tests has the advantage that they are easily repeatable and therefore add a lasting benefit to the project. That's also part of the idea of TDD: to first write a test and then the software to make it pass, rather than writing some software and afterwards experimenting to see whether it even works.

Answer 2

I think you are confusing Unit/Integration tests with mocking. A unit test runs on real classes. The dependencies can be "real world" classes or fake instances - it depends on how you write the tests.

For mocking classes you can use external libraries like Moq or NSubstitute. Or you can use real classes.

The concept of "unit" test is about what you are testing, not how. If a class requires an object in the constructor but you are not using it in the part you are testing, you can also use a real implementation instead of a mock.