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?

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

| improve this answer | |

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.

| improve this answer | |

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