When we test a unit A, any change in another unit B, or a bug in a different unit should not affect our unit test that is for the unit A. In our case, it was easy because we have only one unit. Later, when we develop the test for the quick sort, we will see that this separation is not that simple.

If the unit tests are properly separated, a failing unit test clearly points out the location of the problem. It is in the unit where the unit test failed. If tests do not separate the units, then a failure in one test may be caused by a bug in a different unit than we expect. In this case, these tests are not really unit tests.

In practice, you should make a balance. If the isolation of the units will be too costly, you can decide to create integration tests; and, if they still run fast, have them executed by the CI system. At the same time, you should also try to find out why the isolation is hard. If you cannot easily isolate the units in the tests, it means that the units are too strongly coupled, which may not be a good design.