[MonoDevelop] First go at unit tests
Jacob Ilsø Christensen
jacobilsoe at gmail.com
Thu Dec 1 02:41:01 EST 2005
On 12/1/05, M. Scott Ford <vaderpi at scottandlaurie.com> wrote:
> 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.
I agree here too. As I was trying to fix the search bug it would have
helped tremendously to be able to add some unit tests.
But since there were none in MonoDevelop I was reluctant to start.
It might be worth while to check out Michael Feather's book, Working
> Effectively with Legacy Code. The essay of the same name 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.
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 framework.
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? :-)
> Lluis Sanchez wrote:
> >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.
> >El mié, 30-11-2005 a las 20:04 +0100, Jacob Ilsø Christensen escribió:
> >>The attached patch changes some Makefiles to accomplish testing of
> >>MonoDevelop.Ide.dll. In addition the file TaskTest.cs should be put
> >>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,
> >>Monodevelop-list mailing list
> >>Monodevelop-list at lists.ximian.com
> >Monodevelop-list mailing list
> >Monodevelop-list at lists.ximian.com
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Monodevelop-list