Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I'm having difficulty deciding whether or not using multiple assemblies for a QA system is the right approach to take. Here are some important details:

  • The underlying system is a single assembly system
  • I'm thinking of using multiple assemblies to separate regression, integration, and unit testing. Can these types of testing be split up using NUnit categories instead of assemblies? Which would be a better approach?

Any other comments regarding the use of multiple assemblies vs a single assembly for a QA system would be appreciated. Thanks.

Addendum: Here is some extra information

  • I'm trying to create a QA framework for a large existing project
  • I will start by writing system-level regression tests then work on creating integration and unit tests
  • I am planning on having three layers of code logic: NUnit > Results management > Underlying system logic
share|improve this question
    
Can you provide some more detail as to what you are trying to accomplish? Are these tests to be shared? Are you abstracting what I would call action methods from your tests? –  Dan Snell Jun 6 '11 at 16:54
    
Dan, absolutely, I added an an addendum to the original post. –  sooprise Jun 6 '11 at 17:51
add comment

1 Answer

up vote 3 down vote accepted

They can be split into categories if you want, but test frameworks tend to grow over time, and you don't want to be in the place of refactoring a giant mega test fixture into a number of smaller fixtures. We experienced something very similar and had something like 2000 tests in one DLL; it took hours to complete.

What we've done is both; we create distinct assemblies for close knit sets of functionality that model features or objects. Each assembly has its own namespace that's an extension of a common namespace. Each assembly is also it's own stand alone solution so we don't have to load a single solution with 50+ projects inside it if we don't want to.

We also have a single solution that compiles to "AllTests.dll", which contains instances of each test fixture class. We use this AllTests fixture for selecting a range of tests from the entire project for automated minimum acceptance tests.

This required a middle application we call our test runner that's a wrapper around NUnit and takes an XML file that specifies which test fixtures to run per product. We use this scheme to test 8 different products. Adding a similar layer that tells NUnit which categories to apply can be achieved in this manner if you're set on a single assembly; I can see if it would be possible to provide some sample code to do this if you like.

Using a similar approach will mean a little more work now, but will allow you to snap in new fixtures quickly and manage the size of your framework as it grows.

share|improve this answer
    
With your separate assemblies, do you have one per component and put regression/integration/unit tests all related to that component into that assembly, or do you have separate assemblies for regression/integration/unit tests for a particular component? –  sooprise Jun 6 '11 at 18:00
    
We focus on the components; so we have projects ( assemblies ) that are an aggregate of a number of related test fixtures ( classes ) that all derive from a common set of base classes and interfaces. This lets of mitigate the explosion of projects in the solution while preserving fine grain control over what we run and the encapsulation of test fixtures. –  BrMcMullin Jun 6 '11 at 19:04
    
Ok so I'm assuming you put your regression/integration/unit tests together for a particular component into the same assembly? –  sooprise Jun 6 '11 at 19:09
    
Not exactly; we don't make such a distinction between types of tests. The only grouping we apply is for how the components relate to each other. However, if we did care about the type of tests we were writing, we'd probably still have assemblies defined by the components and have test fixtures for each that we could then select from our test runner application. Seeing all your tests for a particular feature or component makes more sense to us than having parts of it spread all over the solution. –  BrMcMullin Jun 6 '11 at 20:38
add comment

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.