Hacker News new | past | comments | ask | show | jobs | submit login

I'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.



If 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.


Well 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: