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.

I'm in the beginning phases of creating a QA system and I want to make sure that the design decisions that I'm making now make sense and won't bite me in the butt later on. If you have even the slightest nit-picky thing or whatever, please post, I'd appreciate hearing any feedback about this (I'm quite new to it all).

QA solution folder:

  • Assembly For Regression Tests (Class Library)

  • Assembly For Integration Tests (Class Library)

  • Assembly For Unit Tests (Class Library)

  • Assembly for QA related Utilities (Class Library)

Each assembly has this basic structure:

[TestFixture]
public class SomeComponent{
    [Test]
    public void SomeComponentFunction(){
        bool someBool;
        //Some stuff
        Assert.IsTrue(someBool,"");
    }
    [Test]
    //etc.
}

Some specific things I'm wondering (but I'm open to feedback about anything)

  • Are class libraries the appropriate project type to use? I can see the advantage of using console applications so you can run these tests independent of NUnit (but I don't know why you'd do that instead of just using NUnit).

  • I'm having a difficult time understanding the difference between regression level tests and system level tests. For a system level test, it seems like you run an end-to-end test, and compare the final result with some "Standard" result. Isn't that just regression testing?

share|improve this question
1  
If you want feedback on the "testing" aspects of your question, go ask them on sqa.stackexchange.com. If you want feedback on the programming or design aspects, edit this question and remove all the testing stuff. –  SLoret Jun 6 '11 at 15:12
    
Wow, I wasn't even aware of the SQA SE. I'll post over there, thanks! –  sooprise Jun 6 '11 at 15:17

1 Answer 1

up vote 1 down vote accepted

In the spirit of making things as simple as possible: I would consider putting all the different test types in one assembly. You can always split into multiple assemblies if necessary later. You'll probably have some common code between the different test types, starting out with everything in one assembly makes reusing this code (marginally) easier.

I believe class libraries are what the NUnit runner expects. You won't be independent of NUnit anyway, since you use the NUnit [Test*] attributes.

I would not worry so much about the different test types. It doesn't really matter what you label the tests, as long as they help you:

  1. Feel confident about your code
  2. Catch your mistakes
  3. Drive the development forward (if using a TDD-style approach)
share|improve this answer
    
Someone suggested multiple assemblies in case some tests are run per commit or per day. I asked if this could be accomplished using NUnit categories instead of multiple assemblies, and he/she hasn't gotten back to me. What do you think is appropriate considering the different frequencies of running different types of tests? –  sooprise Jun 6 '11 at 15:33
    
You can specify test categories to include or exclude using the nunit-console tool. nunit.org/index.php?p=consoleCommandLine&r=2.5.10 –  codeape Jun 6 '11 at 21:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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