NUnit vs Manual Unit Testing

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 开发者_如何学Gomight come up with. But my concern is what I lose from abandoning NUnit.

---

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)

---

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