[MonoDevelop] First go at unit tests
M. Scott Ford
vaderpi at scottandlaurie.com
Sat Dec 3 03:24:36 EST 2005
> I do not think it is feasible to do it this way. So how do I go about
> testing this class? I see a couple of options:
> * Put the test in the class.
> * Make the class public.
> * Move the class somewhere else.
I think that of all of these, marking the class public is the best
option. Making changes to the accessibility of a class in order to make
it easier to test is acceptable in my opinion.
Tests can be easily added to the assembly so that it has access to the
class. This class and the using statements to NUnit are wrapped in a
conditional compilation section. As long as the section is only on for
test builds, then the normal released assembly will not depend on NUnit.
I think that this would also be acceptable but not preferential.
> It ought not be so hard to unit test a search algorithm. Maybe the
> algorithm should be moved somewhere else?
Moving the algorithm is the best option, if the class must remain fixed.
However, I think that this would only add unnecessary complexity.
> Any good ideas out there? :-)
> On 12/1/05, * Jacob Ilsø Christensen* <jacobilsoe at gmail.com
> <mailto:jacobilsoe at gmail.com>> wrote:
> Ok, I'll give it a try and send the patch to the list.
> On 12/1/05, *Lluis Sanchez * <lluis at ximian.com
> <mailto:lluis at ximian.com> > wrote:
> El jue, 01-12-2005 a las 08:41 +0100, Jacob Ilsø Christensen
>> Exactly my point. The patch I added is in no way a framework.
> It is a
>> small step towards adding a few tests in a specific area. And
> I agree
>> that these small steps might eventually lead to some kind of
>> So. I would like to do some tests for the search thing. Is
> doing it
>> the way shown in the patch the right way or not? :-)
> If you can write the tests for search in this way, I think
> it's a valid
>Monodevelop-list mailing list
>Monodevelop-list at lists.ximian.com
More information about the Monodevelop-list