Continuous Testing

On my build times post from “Don”

And you want to run your tests _every time_ you hit ctrl+s !?

Actually I have run into this viewpoint quite a bit. I see it most commonly from people who are not doing TDD. The reasoning seems to be that in the process of working on a feature they may save 20 times over a few hours then try to build. The “Save” mode is 100% for TDD workflows. If you are not doing TDD workflows then it probably is not for you. That said after having this discussion many times there are other options that better match non-TDD workflows. Let’s go through all four workflows.

Realtime / Saving modes

The realtime (as you type) and saving (when you save) modes are the default modes and are focused on people who are interested in very short TDD feedback cycles. Both automated both your build and will figure out which tests to run and run them after the build is completed. If you type (or save over the top) existing runs are fully or partially cancelled depending where they are in the run.

Auto

Auto will no longer automate your builds. Basically it waits for you to build in Visual Studio and when it succeeds will automate the finding and running of the necessary unit tests. This uses the build in VS as the “commit”, not the saving of file.

Manual

The last mode that is available is Manual mode. In this mode no automation will occur (except for us seeing your builds and keeping our graphs updated). The software will not automate any builds or tests.

Many people have asked “Why does manual mode exist?”.

Manual mode actually has a fairly powerful workflow associated with it that may be beneficial in some scenarios that are not good candidates for continuous testing. In this mode Mighty Moose works just like most manual test runners with a small twist there is a feature called “Run Related Tests” (ctrl+shift+y,r).

Run Related Tests is quite interesting for those who are not in a situation to benefit from continuous testing. Let’s try a quick walk through.

type:

[Test]
public void MyFirstTest() {
Assert.AreEqual(Foo.Bar(3));
}

static class Foo {
public static int Bar(int x) { throw new UnimplementedException(); }
}

Now hit ctrl+shift+y,u with the cursor inside of the test. It will tell you that the test has run (failed).

With cursor on “Bar” f12 (goto definition)… replace code with

return 3;

from current cursor location ctrl+shift+y,r (run related tests). 1 test run one test passes. Imagining they are in different files now use ctrl+f6 and back in your tests. You can just keep flipping back and forth like this.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>