2

Background

I have recently tried to develop a suite of tests for regression testing of a particular application. I have been using NUnit and have had no problems.

I ran into the issue of sending parameters to NUnit tests, for which no satisfactory answer seems to exist.

Question

Say I implement a simple unit tester that loads a class, runs the Startup, Test, and Teardown methods in order, catching exceptions and then unloads the assembly. What are the downsides of doing this versus using NUnit?

In this scenario, I can easily pass parameters to my test cases, or do any other crazy thing I might come up with. But my concern is what I lose from abandoning NUnit.

prestomanifesto
  • 12,528
  • 5
  • 34
  • 50
  • 2
    why do you need to pass parameters to a unit test? sounds like you're testing more than a unit... – nathan gonzalez Oct 02 '11 at 00:22
  • the tests are executed remotely and require information on who executed them for logging purposes. A valid question but unfortunately not what I am asking here. – prestomanifesto Oct 02 '11 at 01:19
  • 2
    @nathangonzalez Depending on what you're testing, it's possible to be in a situation where you want to run the same test multiple times with slightly different data. Parameterized tests make it easy to do that without duplicating essentially the same test multiple times. – Adam Lear Oct 02 '11 at 01:43
  • @AnnaLear, agree to disagree, but unit tests should not function that way in my opinion. if most of the test is shared, write a base class and use that for your tests, don't use the same test for two purposes. – nathan gonzalez Oct 02 '11 at 05:04
  • 1
    @nathangonzalez Agreed, when it comes to reusing the same test for two purposes. I'm thinking of tests that have the same purpose but require different data. For example, [Roman Numerals Kata](http://codingdojo.org/cgi-bin/wiki.pl?KataRomanNumerals) often results in multiples of the same test (number X converts to letter Y) and parameterized tests come in handy to enhance readability and cut down error-prone duplication. (Note: NUnit runs a parameterized test as a separate test with each input, so it's pretty much like writing separate tests.) That's the kind of stuff I had in mind. – Adam Lear Oct 02 '11 at 06:18
  • 2
    And, with parameterized tests you have two options: provide the arguments through an attribute, or use an attribute to specify another method which will produce all the arguments. This allows you to have both readability and advanced capabilities, and still use NUnit. – Lasse V. Karlsen Oct 02 '11 at 16:14

2 Answers2

6

What do you lose? Your time.

If you're working for a customer or business, they are (presumably) paying you to solve business problems, not to write infrastructure code. Some infrastructure may be necessary in order to address the business needs. In this case it's clearly not. You're reinventing the wheel.

Don't fall into the Not Invented Here trap. Use NUnit. It supports parameterized tests. If NUnit doesn't meet your needs, investigate MbUnit or xUnit.net. Or look at SpecFlow, etc. for BDD-style. Or FitNesse for acceptance testing. And this is only a partial list!

If you're writing a test framework on your own for learning purposes, great! If not, you are wasting your time and/or your company's money.

Addressing the technical aspects

JUnit was originally created during a long airplane trip. Back then there weren't a lot of alternatives. Writing a testing framework is not a huge project. Writing a robust one that is full-featured and easy to use is more difficult. Writing test runners, IDE integration, CI integration, code coverage integration, etc. is significantly more difficult. And it's been done. Unless you're Ayende Rahien, don't do it!

In addition to the integration, you also lose any features of NUnit you don't implement (and there are a lot). I don't use all of these, but I do rely on many of them.

(Moved from my comments)

Community
  • 1
  • 1
TrueWill
  • 25,132
  • 10
  • 101
  • 150
0

Two parts mainly independent parts in this question:

  • What are the pros/cons of create our own implementation
  • Why this use case does not reason even to play with the idea of create our own implementation

1) Because this falls to the "reinvent of the wheel" all pros/cons are identical and more general than this question, and all that reasoning apply to this case.

  • We do not utilize an existing stable implementation
  • We probably underestimate the effort hours invested in the existing implementation
  • We lose all the surrounding ecosystem what are built around and on the existing implementation
  • We lose the common accumulated community knowledge
  • Probably we will not achieve the required minimum quality expectations within acceptable timeframe

(in the 1990s I've met a guy who were writing his RDBMS because neither Oracle Database neither SQL Server 6.5 "was not capable" to do what he wanted to do... btw this was a pageable cursor)

2) To send parameters to NUnit tests is just like any other configuration/parameter setting task. You can read your config/parameters from the format your choice (say: XML, json, RDBMS) and do this both in setup, teardown and "test" methods.

You can create your

  • a) completely custom implementation (I mean read your config in setup, test and teardown)
  • b) or you can rely on [TestCaseSource] or some related attribute
  • c) or extend NUnit
g.pickardou
  • 32,346
  • 36
  • 123
  • 268