Search code examples
.netunit-testingseleniumtddacceptance-testing

What is the most maintained newest framework in .NET for writing acceptance tests?

I am practicing TDD for some time now, I want to advance my skills and start doing ATDD, I read about frameworks for ruby and java but didn't hear much about .NET

What is the most maintained newest framework in .NET for writing acceptance tests?

EDIT: After reading more I want to note that I was relating acceptance testing for Websites and Web appliation, any maybe it has to be considered GUI testing as well.

Solution

  • We just started using FitNesse, and so far I am pleased with the decision. A very brief overview:

    1. You write your tests in a Wiki.
    2. You write a 'test fixture' module (which can be a c# assembly) which provides the bridge between the 'tests' in the Wiki and the SUT (System Under Test).
    3. When you run the tests, the FitNesse engine uses reflection to translate the wiki tests into calls to your test fixture assembly, which in turn calls the SUT. The return values get passed back to the Wiki so you can 'assert' them.

    The public interface of the test fixture code is in effect the language you use to write tests in the Wiki. I'm not sure if I explained this very well, but there are plently of resources and videos on the web. I recommend this one from Bob Martin, author of FitNesse.

    I chose FitNesse for a number of reasons:

    • well established framework
    • works with .NET using FitSharp plugin: http://fitnesse.org/FitNesse.DotNet
    • because the tests in the Wiki are written in the language you define in your fixture code, they are readable
    • tests can be called via command line, which we want for Continuous Integration.
    • Robust 1: if the interface of the SUT changes, you only need to change the test fixture code, not the tests
    • Robust 2: We are not testing at the volatile UI level.

    It takes a little time to get used to, but I find it much more reliable than our current concept of testing through the UI. We do this currently in a home-brew application, which works by playing back pre-recorded UI actions and comparing screen shots. When the tests are red it is rarely because the SUT is actually broken. Typically we have timing problems with UI controls not reacting instantly, so we have to build in delays between UI actions, which means it takes all night to run the full suite of tests.