Hi Mike, << I have to strongly disagree with your worries about setting the current directory. I know this is fixed, but I wanted to explain why I think it is okay to change that directory. The directory your tests think is the current directory shouldn't matter, but it is very helpful to be able to use relative paths in your tests. If I want my test to load an xml file to populate a dataset I don't want to put a fully qualified path to that file. It might be that my machine is set up differently than another developers machine and it is quite possible that it looks different than a developers box. >>
OK, I'll agree it is convinient for the reasons you specify. However, let me argue a little bit on the other direction (by now you've probably realized I like to argue ;) ): My problem is not really with the unit testing code per se. Rather, my argument is that changing the current directory, while it will simplify (only slightly, keep reading) writing the unit testing code, will also easily mask potential bugs in the underlying code, too. That, I think, is unacceptable for a tool based on the premise of comprehensive unit testing. But that's just my opinion, of course. As for making it easier to write the unit tests, I'll argue that writing a small helper function to return the directory the assembly was loaded from (or get the full path to a file relative to that directory) is fairly trivial. Hell, you could add such a helpr function to the NUnit api and encourage testers to use it, instead of forcing the current directory on them. << In one of your early posts you say the problem with the nunit2 task is that it can't take an assembly file name. That wasn't actually true, but it was very easy to think it was. I made a huge mistake in the first implementation, or I should say at least one huge mistake. I wrote an attribute called fork on the test. If that was set to true all tests were run in a different app domain using the TestDomain class. That would take a file name. It could even be relative to the nant build directory. The behavior when fork was not set was frankly crap. I was trying too much to mimic some of the original nunit tasks abilities. It has the ability to run in the nant process or not. To make matters worse I made the default to fork false. Many people I know that are using nant did eventually figure it out, but not without great pain. I appologize for that. Once that fork attibute was set most things worked fine. >> I haven't taken a look at NUnit's code in quite a while, so this might have changed. I believe my argument at the time was that NUnit didn't expect an assembly file name, but an assembly name (quite different things in .NET). Perhaps I remember it wrong though. One of the problems with all this was the way that NUnit created the test AppDomain, which involved setting the appdomain's base directory (used by the assembly resolution process) so that the nunit runner injected into the appdomain could just use AppDomain.Load() to load the assemblies containing the unit tests. While this certainly made it easier on NUnit itself, it completely prevented something we could do in NAnt's support for NUnit 1. That allowed me, as a developer, to just rely on the NUnit dll to be on NAnts binary directory, and know that the tests would run OK. This, for me, greatly simplified using Nunit together with tasks, and made it easier to just have nant by itself and still being able to use nunit. In fact, I don't even install nunit on my machine, as all I needed was nant. This isn't as seamless as it is with NUnit 2.0, and required copying and referencing some assemblies around, which I didn't quite like. Witness of this is all the trouble we got with the NAntContrib build when NAnt's own unit tests were moved to NUnit2.0. I consider NAnt and NUnit to be pretty good partner tools, and I've had tons of success with them. I just think it is sad to see how Nunit 2.0 was developed and pretty much redid some of the things we did here at nant to support them, do them differently (and in my own opinion, sometimes poorly). OTOH, maybe I'm just wrong. << Apparently I still don't get the crux of the problem and I will still ask for your help explaining it. Since I didn't get it last time maybe you could try to explain it to me again. That is all I'm asking. I'm not trying to start a fight >> Neither was I, and I apologyze if it came out that way. I'm just sort of frustrated with this whole deal, and particularly frustrated at how NUnit 2.0 was built (hell, we haven't even upgraded at work... the problems described above, plus having to do source code changes to 300+ tests is not something we want to do right now). So, at this point, I'm seriously considering rebuilding a large portion of the NUnit test runner code to be able to do things as I want them (which I'll be the first one to say is likely not how other people want them to be) for my own personal use, but it will have to wait until I have the time. -- Tomas Restrepo [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
