Because you are writing Module Tests.
There is a difference, and both have their advantages.
A Unit test should be small, and constrained. Almost everything in a unit test is either Plain Old Data, or mocked out collaborators. The only "real" object is the one whose behaviour is being validated. This makes them fast, and when they fail, obvious that the unit's code itself is incorrect (assuming the data and the test itself are accurate).
A Module test is about orchestration. It has several real objects (and perhaps a few mocked boundary objects) that are orchestrated to see if they can achieve a particular outcome. The presumption is that each individual object is "correct" but because they interact these interactions might not be "correct". As such when they fail, the clear reason for the failure is that the interactions are incorrect. This might require adjustments to the individual objects, or an alteration to the configuration of the orchestration (assuming the test setup and validation are correct).
Composition and Inheritance
Composition clearly puts the test into the Module category. There are several "real" objects working together to obtain an outcome.
Inheritance does too, though it is far from obvious when the test has only one "real" object. The reason is that the "real" object is a composition of the inherited with extra data and behaviour.
Now you will need to squint a little. A class is by definition a Module, because it is a composition of data and behaviour. Yet tests written against the majority of classes that use just a single instance and mock out the collaborators will be considered unit tests.
The distinction depends on the level of analysis to some extent, testing a database engine even if presented via a single object cannot be considered a unit test.
Conversely a String of Characters (where both are classes) would probably fall into the Unit Test category, even though those Character objects would be separate "real" objects, and they would be orchestrated to work together.
I've no hard and fast rule to disambiguate where something stops being a unit test, and starts being a module test. My hunch centres around how much externally imposed orchestration occurs.
- A string has little to no externally imposed orchestration, it behaves the same ways regardless of its contents. Whenever a given character is searched for, regardless of whether it finds a location or not, it will always conduct the search in the same way.
- A database has much externally imposed orchestration, creating/dropping an index changes the speed of particular operations, which fields make keys alters the shape of storable data, even what tables exist. It has a meta-behaviour from which to produce a desired behaviour. Should the configuration be incorrect, the object will not behave correctly.
Unit tests do not need a particular order of execution. Because they test for independent properties, and it is clear that their failure is because the object does not live up to its expectations.
Module tests do need an order of execution. They should not be run till after each of their "real" collaborators have been unit tested.
However I would still execute the Module tests even if their Unit tests failed. At least as far as time permits.
Because there is the chance that the Module behaves as expected even if its components do not. This might illuminate the tests themselves as incorrect, or provide insight into why a particular configuration works around the component level defect.