The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Experimental unit test framework (C#/VB), would like feed back

I created an experimental unit test framework for C# or VB.NET named www.QuickUnit.net.

QuickUnit.net differ from the xUnit style.

I would appreciate some feed back ?

Thanks.
Frederic Torres Send private email
Wednesday, July 04, 2007
 
 
How is it different from nUnit?
Craig Send private email
Wednesday, July 04, 2007
 
 
The first idea was to express the tests by only declaring the input parameters and expected output value or exception using decoration. No coding.

This was good but limited.

So I also added the concept of [Test]MyTest() like in Nunit but with parameterized tests.

The test source code is in the class tested.
There is no extra program.

check www.QuickUnit.net, there are plenty of example.

Thanks.
Frederic Torres Send private email
Wednesday, July 04, 2007
 
 
It seems to make the assumption that the only things I want to test are return values from method calls. That's not going to cover 95% of the stuff I'd like to test, unfortunately. That said, I've only really glanced at the homepage. :)

You might want to check out MbUnit - it's closer to the NUnit style of testing, but it uses attributes to set up different sets of values to test against.
Thom Lawrence Send private email
Wednesday, July 04, 2007
 
 
Thanks Thom for your first comment,
You are right the first idea was to

  test return values from method calls using no programming in a very simple way.

And of course this was limited, that is why I added the attribute [Test] like in Nunit
but added parameterized test like in mbUnit.

But the difference is that the tested code and the test code are in the same class.
This give a very quick way to write and test code.

It's kind of a minimalists approach to test driven development.

At the same time make the class a little bit messy
(download the source code and check out the class CPerson.cs).
That is why I asking for feed back.

Check out http://www.incisif.net/quickunit.net/default.asp#TDD1
Frederic Torres Send private email
Wednesday, July 04, 2007
 
 
I have been thinking lately about automating tests specifically involving methods that return a collection of objects. For example, I want to test a 'getOrders' method that returns a collection of 'Orders' objects, and verify that all the properties of those Orders match those that I previously input.

Does JUnit do this? Do I need DbUnit? Does DbUnit work? I have been meaning to Google these matters, but thought I'd ask here as well.
Greg Send private email
Thursday, July 05, 2007
 
 
Thanks greg for your comment that is actually a great idea.
I added a sample close to what you asked in the file CPerson.cs project Sample01.

I am still 100% sure about this way to write unit test.
It is good for TDD, but make the class source code a little bit messy.
Frederic Torres Send private email
Thursday, July 05, 2007
 
 
I meant

  I am still NOT 100% sure about this way to write unit test.
Frederic Torres Send private email
Thursday, July 05, 2007
 
 
Personally I like to seperate my code from my test code. And although the attributes are a minimal interference I am somewhat concerned about the maintainability of these attributes.

I treat my unit test code (the NUnit type of classes) the same as my product(ion) code. It needs to be maintainable and exibit all the qualities you'd expect from any source code (but I think maintanance is the biggest issue for unit test code).

It seems that using these test code attributes will force me in (partially) repeating myself concerning test data.

Personally I like the encapsulation a unit test class gives me. Although I must admit that there is usual a 1:1 relation between the unit test class and the class being tested, I still have the power of the class (inheritence, method overrides etc).

Also a test method (on a test class) allows you to setup a scenario before calling the method to be tested. I'm not sure how that would work in you solution. It seems that you only shoot parameter sequences to the method (containing the code attributes).
Marc Jacobi Send private email
Friday, July 06, 2007
 
 
Thanks Marc for your comments.

I am also struggling with the idea of having the code and the test code in the same class.

About repeating the test data. That is a good point. I will try to come up with something. (In my todo list).

To avoid being stuck just defining input and output via attribute.
I also created a [Test] attribute like Nunit with parameterized test syntax.

To be frank, It is a little bit messy.

But for somebody that do not practice TDD, like me, I have the feeling QuickUnit.net could help me make the Jump.

Because testing and coding are in the same file, quick to implement and at the touch of a button to execute the tests.
Frederic Torres Send private email
Sunday, July 15, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz