Running the build can take a long time.

Why run all the tests when a given change probably only has the potential to break some of them?

You should be able to build a dependency graph of all the code that each test could possibly run, and then avoid running tests that couldn't possibly be affected.

Is there anything that does this?

closed as off-topic by gnat, GlenH7, user40980, Kilian Foth, World Engineer Nov 11 '13 at 23:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, GlenH7, Community, Kilian Foth, World Engineer
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Could you elaborate why you think this is useful, perhaps by giving an example? Running the unit tests shouldn't take a long time. Integration tests and other system tests may, but those are by definition touching a lot of code so you'd still run most of them on every change. – user7043 Nov 8 '13 at 20:28
  • 6
    Murphy's law - the one test you don't run is the one that would have saved you. – Dan Pichelman Nov 8 '13 at 20:49

Infinitest does this for Java. From their website:

Each time a change is made on the source code, Infinitest runs all the tests that might fail because of these changes.

I use it as an eclipse plugin and any time I rebuild (I have it set to build on save) the project it runs any unit tests which cover the code I have modified.


Visual Studio Team System has done this via Test Impact Analysis since VS 2010.

There's walkthrough of how to set up a build environment here that includes TIA.

It works with varying degrees of success depending on the structure of the codebase. For example: I don't know for sure, but I can only imagine that statically analyzing dependencies in a project that heavily depends on runtime DI isn't very easy.

In any event, for incremental builds/checkins, it makes sense to use it while daily builds run the whole suite.

Not the answer you're looking for? Browse other questions tagged or ask your own question.