Hi Tomas,
Sorry I left the subject off somehow on my last post.
I have gone through all of your old posts in nant-developers. I was hoping to get a summary from you. I'd rather debate the issues then just "take over". I have an oppinion but I also know I might not be right. I don't want to just go ahead and do what I think is right. I want to try and come to some consensus.
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.
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.
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, I'm trying to get some information and have a discussion. You can certainly continue with nunit 1.0 or some other framework. But I'd rather try to work with you to come to a common understanding on the issues. I'm not asking to take anything over. I would rather work with you on this. I am, however, a big fan of consistency. I don't believe that tools like nant should try and change behavior of the tools like nunit. Consistency in behavior, even if that behavior is not what is desired, is really important. The right way to change it is through dialogue. I'm asking for that dialogue now. I didn't get convinced last time, but I fully recognize that I might have missed something or just not understood.
I can promise you that not everyone is content with the way nunit 2.0 works. Most seem to be, but there are plenty of people who share your oppinion if not your reasons. Those of us that write nunit haven't been convinced yet, but we are listening. We are constantly trying to improve it and get feedback on it. We do feel we know a bit about unit testing. None of us are new to the subject. We consult with the XP and Agile community on this stuff often. We have some strong beliefs on how tests should be written, but we are always willing to listen. One of the reasons we like open source projects is it gives us the chance to say, "We don't think we want to do it that way, but here is the source code, go right ahead and implement it." Most of the features we are currently implementing are from outside requests, so we are listening. But there are some things we just don't believe to be the right way to do things and we won't implement. For example many people have asked for an order attribute for unit tests. We don't believe unit tests should depend on other unit tests running first. I'm not trying to start up that debate here but if someone wants to take it up in another thread I'm happy to discuss it.
So without the feedback we can't change, and I'm sorry I'm asking you to go over the argument again, but I really think that would be useful. Some of the discussion is spread over several emails on two lists. I thought putting it in one place and revisiting the dialogue would be good.
Mike Two; Putting the tWo in Thoughrks
| "Tomas Restrepo" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 02/26/2003 05:14 AM
|
To: <[EMAIL PROTECTED]> cc: Subject: Re: [nant-dev] (no subject) |
Mike,
I'm certainly not saying drop NUnit 2.0 support in favor of 2.1 support.
I'm still asking what those short commings in the runner where. I haven't seen anything on the nunit mailing list, at least not for quite some time. We can't fix it if you won't tell us what the issues are. I'm not getting a lot of complaints on it on the nunit mailing lists. So please tell me what the issues are.
I did post about some of them once. I even got a reply from you, but it seems no one still got the crux of the problem. So it seems everyone is just content with how NUnit 2.0 works.
I have to admit I had an easier time with the original implementation of nunit2 support than this one. I completely admit that I made a serious error in judgement using the fork attribute. This seemed to cause quite a bit of confusion, but I very very intentionally wrote it to use TestDomain. I knew what the plans for that interface were. I also knew that the interface RemoteTestRunner was much more likely to change than TestDomain.
If you want to take it over, be my guest. I'm pretty much dropping NUnit 2.0 myself, and will probably look to either using a different framework or sticking with v1. NUnit 2.0 made it way to complex for my taste to do things how *I* wanted them.
--
Tomas Restrepo
[EMAIL PROTECTED]
