Interested in Feedback on QA System Design

Question

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?

Answer 1

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)