Andrew Stopford's Weblog

MbUnit has been driving me insane. I don't want to leave it behind; I love the additional functionality it offers when running via TestDriven.NET, and the output is very pretty.

However there are so many problems with the project right now that I don't know where to begin--I'm at my wits' end and am ready to go back to NUnit myself.

1) There's a project homepage at tigris, but it's hopelessly mangled and difficult to read, appearing to also be a page for QuickGraph and ReFly. The page doesn't even offer a download of its own product!

2) There's no standalone installer. What if I don't want TestDriven.NET?

3) The code doesn't appear to be public. At least if it is, I can't find it. So, it's effectively closed-source.

4) The GUI is ridiculously slow. I have a project consisting of around 60 binaries (exes and dlls) and the GUI takes a good ~5 minutes to load the project. Meanwhile, the only clue I get that something's going on is in the status bar--I can feel free to interrupt the background thread by messing around with the menus and get exceptions if I want. Hint: a UI where you effectively can't do anything else during a process doesn't need a background worker. It needs an hourglass.

5) It's impossible to tell who's in charge. First it was this one guy, then it was this other guy, but none of this is clearly communicated, ANYWHERE.

6) There's no operating Wiki (I know there's one but it's dead and full of dead links and nobody contributes.) The only community appears to be mailing lists. What century is this, again?

7) There is absolutely none, zero, zip documentation. Anywhere. Originally I guess you could get some off-the-cuff stuff from some guy's blog, but that blog appears to be dead at the moment.

8) And lastly, it appears that the console app--get this--can't find it's own dependencies unless it is both executed from, and the test project file (.mbunt) resides in the actual MbUnit application folder.

So, yeah. It's a great idea but it doesn't appear that the execution is there. It's just, basically, impossible to use.

Amended notes to my previous comment:

So it looks like you can get the code. If you want to use an SVN client. I take it back about the code not being available--change that to "very very hard and annoying to get."

And about the console app--I still can't get it to work. My most recent attempt had me actually copying mbunit.cons.exe into the folder that had all of the assemblies to be tested, and running it from there. At that point the app was able to at least find its own DLLs--but it still didn't test. It just threw an exception about not being able to assembly "tests" or one of its dependencies, "tests" being the name of my .mbunit project file.

So, still unusable, since I can't integrate with CruiseControl this way.

Ron,

Since you did'nt leave a emaill address I can't contact you directly to help you overcome your issues. I strongly advise you to join the MbUnit mailing lists and voice your concerns and issues there, MbUnit has a community and the best way to get advice and help on problems and issues is to be a part of it. Updates on what is happening with the project is shared to the mailing lists so its important that you join them.

Before I address the issues you are experincing let me remind you that MbUnit is coming away from a closed source model to a open source model and this is still a work in progress. As such there is still a lot of work to do and the more people help the easier this will become.

1) The homepage does need updating and this is being worked on.

2) For the moment you will need to compile the MbUnit source. This is an added level of complexitity for a lot of folks and we hope to offer a MbUnit installer ASAP.

3) The code is opensource on Tigris under CVS not SVN, the license is available from

http://www.testdriven.net/wiki/default.aspx/MyWiki.MbUnitLicense">http://www.testdriven.net/wiki/default.aspx/MyWiki.MbUnitLicense

A SVN branch has been available but this is not being used. Updates to the source will be made to CVS until such time as we can make the Tigris SVN workable with CCNet.

4) If you feel this is a defect then please share with other users, see what they have done to overcome this issue. Also raise the issue on the Tigris issue tracker, if the defect is not raised it cannot be dealt with.

5) This has been the net effect of the move from a closed source model to a open source model. A lot of administration remains but if you have any doubts, MbUnit is opensource under my leadership with Peli offering advice and guidence to the community. My involvement was blogged here.

6) The wiki is available from http://www.testdriven.net/wiki/default.aspx/MyWiki.MbUnit and is updated. Community contributions are very welcome.

7) While Pelis blog and the wiki remain a good source of documentation there is still a lot of work to do I agree, the more people help out the more documentation we will have.

8) Again cast this to the lists.

On your CCNet point, have you tried the NAnt or MSBuild tasks.

Okay, well here's the deal.

I am going to have to go back to NUnit. I eagerly await the time that I can use MbUnit--I like it, I really do, it's an impressive piece of work, and I *want* to use it so badly I can taste it, but at this point in the project's lifecycle, it's just not ready for production use.

Let me tell you what finally tipped me over the edge (and you're free to duplicate these comments anywhere you want.) Please keep in mind that these comments are meant to be constructive. I apologize for the somewhat irascible tone my comments took yesterday--I'm sure you can understand, being a developer, riding a wave of frustration until you wipe out.

On your advice, I got the latest code from the CVS repository at Tigris.

First of all, the fact that the guest password is "guest" may be some kind of standard convention to people who use CVS a lot, but I didn't know this, and this fact was well-hidden at the bottom of the instruction page.

After I got the source, I looked through it. It appears that the standard build method is MSBuild. This is fine and good, but I don't have access to MSBuild--I do production work, and we use Visual Studio 2003. I have no access to 2005--even if I did, I wouldn't use it, because it's a beta. It's unreleased software and I write mission-critical production data analysis code.

So, I figure, I can write an NAnt script for it, but before I do that, I decide I'll open the solution and look it over.

The solution files are all Visual Studio 2005 solutions. So I can't open them with the most recent Visual Studio, which is 2003--I would have to actually muck up my development environment by installing a beta version of VS 2005.

I'm really trying here--I really want this to work--so I just decide I'll go ahead and build it with NAnt anyways.

Except that the product actually has a .NET Framework 2.0 dependency. A beta, non-production version of .NET. It doesn't just SUPPORT 2.0, it REQUIRES it. At this point, if I want to use MbUnit, I have to actually pollute my production build environment with .NET 2.0. And that is simply not going to happen. Even if I were willing to ride the bleeding edge like that, which I'm not, but even if I were, my company has policies specifically forbidding the use of beta production environments like that.

I'm stymied, at this point. I've spent over a day of my time trying to get this to work, and I consider this time well spent. MbUnit is an outstanding product which I really want to use, and which I will use when it's ready for production use, but at this point it's simply unusable for me for the reasons detailed above.

Thanks for your hard work and I encourage you to continue developing MbUnit to the point where I (and, I imagine, others) can use it.