Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as off-topic by gnat, GlenH7, MichaelT, 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, MichaelT, 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. –  delnan 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

2 Answers 2

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.

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

share|improve this answer

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