Forums

Gallio/MbUnit 3.1 Released

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Gallio/MbUnit 3.1 Released

Postby Charles » Tue Oct 06, 2009 1:18 pm

I just noticed that Gallio/MbUnit 3.1 was released recently. You can find it at http://www.gallio.org/ with release notes here. And there is a book!

I have stubbed out a Gallio wiki page for notes and tips.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Gallio/MbUnit 3.1 Released

Postby Charles » Tue Oct 06, 2009 2:52 pm

Ahem, well I didn't realize at the time that chapters 5, 6, 7, 8 and 9 of the book said "TODO". :o

Other than the nice test runner and out-of-the-box type verifiers, I'm not seeing major advantages over Cobra's built-in test capabilities. However, I'm using this on a client's C# project so I'll learn it more thoroughly as way to see where we can improve.

At some point, it would be nice if Cobra had options like -test-target:nunit and -test-target:gallio so that its unit tests could be put through a test runner.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Gallio/MbUnit 3.1 Released

Postby eric.sellon » Wed Oct 07, 2009 10:45 pm

I can understand that your client wouldn't want you to do this, but what about using Cobra as a unit test framework for .NET? I'm thinking that you could compile, for example, the C# classes you want to test into an assembly (not sure what else you would compile C# to) and then your Cobra program could test the classes from the assembly (after loading it of course). I don't see any problem with Cobra as a unit test framework for .NET. Well actually the only problem I can see with it is that Cobra generates an assert exception on a test failure so that means the other tests won't run after that. Is that something that could be changed? Would we be able to use it as a unit test framework on the JVM (a tough sell with JUnit, though)?
eric.sellon
 
Posts: 24

Re: Gallio/MbUnit 3.1 Released

Postby Charles » Thu Oct 08, 2009 5:48 am

Some people are doing exactly what you describe. Plus, when you do unit testing in C#, you normally put the classes to be tested in a separate DLL anyway, so that part is not any different. Having "Foo.dll" and "Foo.Test.dll" is a typical approach.

But this client is very picky about which tools are used. That's okay for now. I have client projects in C#, Python and Ruby right now which keeps me well informed about the pros and cons of these languages and associated tools because I'm actually using them on real projects. I can stomach that for another year or two for the educational benefits. :-D

Re: the exception, I took that approach so I could get a stack trace and also so I could use a debugger on a failure. However, I'm open to a patch that would let you run in either mode.
Charles
 
Posts: 2515
Location: Los Angeles, CA


Return to Discussion

Who is online

Users browsing this forum: No registered users and 27 guests