3 ms·
This doesn't make sense to me. If you know that A depends on B and you run your test suite while B is broken, then both A Suite and B Suite will fail. But the o
by Jtsummers 4y ago
This doesn't make sense to me. If you know that A depends on B and you run your test suite while B is broken, then both A Suite and B Suite will fail. But the order is irrelevant, you'll know that B (the one A depends on) is broken and that should be the focus of your investigation. Why would there be any confusion if the tests executed in a random order?
- Hirrolot 4y agoI've answered it in the other comment -- because I might not know the entire module dependency graph. For example, if the code is not mine.
- Jtsummers 4y agoIf the code isn't yours then you have to hope they ordered the tests correctly or, you know, figure out the dependency order. Which isn't hard: - Use a static analysis tool that kicks out a dependency diagram. That literally shows the dependency order. - Look for import/include/using statements. That shows the dependency order. - Look for inherits/implements part of class definitions. That shows the dependency order. - Look at the build commands. It'll tell you the dependency order. - When you see a function, constructor, whatever being used, you have a dependency. And if the code is yours, and you don't know the dependency order, then fix that. Write it down or something.
- Hirrolot 4y agoWell yes. But this all requires additional movements on my side. On the other hand, if the tests are always ordered such that dependencies are tested first, then I won't have to deal with the approaches you've mentioned. Ideally, a test framework should enforce the order based on the project ontology. They don't usually do that though because they cannot easily examine the code being tested to extract the necessary dependency information.