Alex, I�m always up for learning something new. I've not toyed with Reflection much but I'm will to try it.
As a workaround to my conditional compilation situation, the other developers and I have decided to place our unit tests in Debug mode and make our builds from there. You can email me privately if you wish to elucidate further on Reflection unless you think the rest of this group would like to loiter in on the conversation. Thanks, Brian > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:nant-users- > [EMAIL PROTECTED] On Behalf Of Osbun, Alex > Sent: Wednesday, March 31, 2004 11:19 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Nant-users] Nant & Unit Tests From Conditional Compilation > > Hey Brain, > In reference to testing private methods and data members in separate > classes, you can try using the System.Reflection namespace. Let me know > if you would like some additional help. > > Alex > > -----Original Message----- > From: Brian Beaudet [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 30, 2004 9:52 AM > To: [EMAIL PROTECTED] > Subject: RE: [Nant-users] Nant & Unit Tests From Conditional Compilation > > > Gary, > > I appreciate your input and I'm trying to digest it now. How do you > reference the private methods you will be testing if they are in a > separate class (or project)? > > Secondly, is this separate unit testing class in the same solution? Or > another solution altogether. > > Lastly, I've only seen examples of conditional compilation using only > Debug or Release. If I decide to go with my original route with a > separate UnitTest configuration (which mirrors Debug in every way with > the addition of a new preprocessor directive called TEST), how do I set > this build up in a .build file? > > Thanks, > > Brian > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:nant-users- > > [EMAIL PROTECTED] On Behalf Of Gary Feldman > > Sent: Tuesday, March 30, 2004 8:03 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [Nant-users] Nant & Unit Tests From Conditional > Compilation > > > > ----- Original Message ----- > > From: "Brian Beaudet" <[EMAIL PROTECTED]> > > > > > What I'd like to do is make a build and run the unit tests (as a > build > > > verification test). Now, should I only build the UnitTest > configuration > > > I've defined and is that a valid approach? Or should I run the > UnitTest > > > configuration, run the unit tests and if they all pass, then run my > > > debug or release configuration (depending on my needs at the time)? > > > > You need to identify what you're trying to accomplish, and what the > > resource > > costs are. > > > > In the typical nightly build situation, the primary purpose is to > identify > > any newly introduced bugs. The product of the build won't be going > > anywhere. Thus the usually approach is to do a debug build, and then > run > > the tests on that. If anything shows up, then the developer have a > ready > > build to debug (which is a particular advantage if their development > tree > > doesn't match the nightly build). Conversely, because developers are > the > > only ones likely to see a debugging build, there's no harm in > including > > the > > extra testing code in the output. > > > > Release builds are trickier. If your test code is small and > unobtrusive, > > you may not care if you ship it to the end users. But often that's > not > > acceptable. The bottom line in that situation is that you either have > to > > do > > two builds, or forego running the unit tests in the Release build. > Either > > way, you're not going to be unit testing the final product - which may > or > > may not be ok, depending upon the quality of the rest of your test > system, > > as well as your bug patterns and code design. > > > > For this reason, I think a better approach is to put the unit tests > into a > > separate module, and rely on the internal access modifier to give them > > access to the "mostly private" data of the application code. > > > > Gary > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > _______________________________________________ > > Nant-users mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/nant-users > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Nant-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-users > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id70&alloc_id638&op�k > _______________________________________________ > Nant-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
