[MonoDevelop] First go at unit tests

[M. Scott Ford]

I would argue that the only tests that are a waste of time to write are 
the ones that either always fail or are never run. One of those states 
usually leads to the other. However, with that being said, I do have 
some advice for the current situation.

With an existing code base, it has been my experience that adding tests 
just for the sake of adding tests is not all that useful. Instead, just 
write tests to cover all of the new stuff that you write. This would 
include all of the bugs that you fix.

It might be worth while to check out Michael Feather's book, Working 
Effectively with Legacy Code[1]. The essay of the same name[2] is also a 
very useful read. It may help you decide if you think it is worth buying 
the book.

Either way, my advice is not to try and tackle the problem by adding a 
test framework. Just start small and ask yourself. "How do a write a 
test for this bug that I am working on." And then only write enough code 
to solve that problem. In the end, you may end up with a test framework 
after all. But then again, you may realize that you don't need one.

[1]: http://www.objectmentor.com/resources/bookstore/books/welc/
[2]: 
http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

-Scott

Lluis Sanchez wrote:

>Hi,
>
>Before starting to build this test infrastructure it would be good to
>think about what are we going to test and how to do it.
>
>About what: writing a test for Task is easy, but I feel it doesn't add
>much value. I know it's just an example, but what I mean is that we need
>to decide which classes are important to test. The current API is not
>final. Some classes will change, some will desapear, some will be made
>private, so writing tests for those would be a lose of time.
>
>About how: MonoDevelop.Ide (and most of the MonoDevelop.* assemblies) is
>not just a standalone dll, it's an add-in. It needs to be loaded by the
>MonoDevelop runtime, and it needs to be properly initialized. Otherwise,
>it is not guaranteed to work at all.
>
>This could be a problem with NUnit. I know that NUnit can do per-class
>test initialization, but we would need per-assembly initialization.
>
>Another problem I see is that many of the classes in MonoDevelop.Gui are
>designed to run in the GUI thread, and all in the same app domain. AFAIK
>NUnit creates its own test threads and app domains, so we'd need to
>think about how to handle this.
>
>Lluis.
>
>El mié, 30-11-2005 a las 20:04 +0100, Jacob Ilsø Christensen escribió:
>  
>
>>Hi.
>>
>>The attached patch changes some Makefiles to accomplish testing of
>>MonoDevelop.Ide.dll. In addition the file TaskTest.cs should be put
>>here:
>>
>>monodevelop/Core/src/MonoDevelop.Ide/Test/MonoDevelop.Ide.Tasks
>>
>>Right now it is assumed that the nunit assemblies are in the GAC and
>>that nunit-console.exe is in the path.
>>
>>make test builds MonoDevelop.Ide.dll and MonoDevelop.Ide.Test.dll and
>>then runs nunit-console.exe on MonoDevelop.Ide.Test.dll.
>>
>>Is this the way we should go? Will someone try it out on their system
>>to see if it works as expected?
>>
>>Thanks in advance,
>>Jacob
>>_______________________________________________
>>Monodevelop-list mailing list
>>Monodevelop-list at lists.ximian.com
>>http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>    
>>
>
>_______________________________________________
>Monodevelop-list mailing list
>Monodevelop-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/monodevelop-list
>  
>