[MonoDevelop] First go at unit tests

Jacob Ilsø Christensen jacobilsoe at gmail.com
Tue Dec 6 08:29:25 EST 2005 

Or maybe have an environment variable defining AddIn paths, MD should load
AddIns from?

/Jacob

On 12/6/05, Rafael Teixeira <monoman at gmail.com> wrote:
>
> I think, it may be a little more reasonable to instead of
> copying/removing the test addin from the addin directory, have a
> command line argument added to MD that either:
>
> -- Append a new addin directory to be scanned, ex.:
>
> md --testAddinsDir ./testaddins/bin
>
> or
>
> -- Specifically gives the path to a specific addin to be loaded, ex.:
>
> md --testAddin ./testaddins/bin/searchtester.dll
>
> That way if something goes wrong no test addins will be left behind in
> the addin directory...
>
> It could also help (to avoid people using them for other purposes) to
> make MD just load/execute the addins and leave, when processing such
> options.
>
> Just my two cents,
>
> On 12/6/05, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> >
> >
> > On 12/5/05, Lluis Sanchez <lluis at ximian.com> wrote:
> > > Hi Jacob,
> > >
> > > >
> > > >
> > > >         But the main reason is that it won't help in building up a
> > > >         test
> > > >         framework for Monodevelop. Your test would only be testing a
> > > >         particular
> > > >         implementation of the search engine, not the *MonoDevelop*
> > > >         search
> > > >         engine. If that is what you want to do, ok, but I don't
> think
> > > >         it is the
> > > >         correct path.
> > > >
> > > > That is actually what I wanted to do. Test a particular
> implementation
> > > > with a unit test.
> > > > And we then know that *MonoDevelop* search works if all the
> particular
> > > > implementations are tested individually.
> > >
> > > I rather prefer one single test for all implementations, which defines
> > > the expected common behavior.
> >
> > True, we need one test the the common behaviour. But it would be nice
> with
> > tests for the specific implementations (though they might be of a lower
> > priority).
> >
> > > >
> > > >
> > > >         If we next month decide to drop the GtkSourceView based
> editor
> > > >         and
> > > >         implement our own manged editor, all those tests will be
> > > >         useless, and
> > > >         we'll have nothing to ensure that the new editor does the
> > > >         search in the
> > > >         same way as the old did, and that there are not regressions.
> > > >
> > > >  It is true that they will be useless but that argument goes for all
> > > > code that is thrown away.
> > > > But as long as we use the GtkSourceView based editor they will not
> be
> > > > useless.
> > >
> > > If we write a test for the search engine, we don't need to throw it
> away
> > > if we change a particular implementation. We are reusing the test and
> > > making sure that everithing keeps working in the same way.
> > >
> > > If we change the search engine, we need to throw away that test, of
> > > course. But at least we would need to write only one new test, not one
> > > for every implementation. That's a big win.
> > >
> > > >
> > > >
> > > >         >         > * Make the class public.
> > > >
> > > >         Making a class public is a very serious decision. You are
> > > >         adding the
> > > >         class to the public API, which means that users of that
> > > >         library may use
> > > >         that class, so you can't change it without breaking the
> binary
> > > >         compatiblity.
> > > >
> > > >         So, if you make public an internal implementation class, it
> > > >         means that
> > > >         changing the internal implementation might break assembly
> > > >         compatibility.
> > > >         And that's really bad.
> > > >
> > > > I agree, it is also the option I like the least.
> > > >
> > > >
> > > >         >         > * Move the class somewhere else.
> > > >
> > > >         I don't see how this can help. If you move the class to
> > > >         another assembly
> > > >         you'll have to make it public so the original assembly can
> use
> > > >         it, and
> > > >         you'll have yet another assembly dependency.
> > > >
> > > > The reason I added this option was that I did not think the search
> > > > algorithm belonged in a GUI class.
> > > > So moving it to another class that was not so bound to the GUI might
> > > > make it easier to test.
> > >
> > > The MonoDevelop search algorithm is already independent from the GUI.
> > > The algorithm is implemented in the DefaultFind class, in the
> > > MonoDevelop.Ide.Gui.Search namespace (which has Gui in the name, but
> > > this specific class has no GUI dependencies). This algorith uses a
> > > combination of ISearchStrategy, IDocumentIterator and ITextIterator to
> > > find text.
> > >
> > > Some months ago I added a SearchNext() method in ITextIterator. The
> goal
> > > of this method was to improve the performance of the search operation.
> > > The problem was that the generic implementation of the search
> algorithm
> > > was much slower than the native search method provided by
> GtkSourceView.
> > >
> > > So, right now an ITextIterator implementation can provide native
> search
> > > support through this method, and the main search algorithm will use it
> > > if it can. It won't be always possible, since the MonoDevelop search
> > > engine provides more search options than what GtkSourceView can
> provide
> > > (for example, native search won't be used when looking for 'whole
> > > word'). The search engine calls ITextIterator.SupportsSearch to find
> out
> > > if the native search can be used for a particular search operation.
> > >
> > > Of course, all this is completely transparent to the user of the
> search
> > > engine API.
> > >
> > > In summary, SourceViewTextIterator.SearchNext is a fast
> > path
> > > implementation of the search algorithm, and it certainly needs to
> belong
> > > to a GUI class and depend on GtkSourceView.
> > >
> > > >
> > > >         I already said it many times, but here is it again: many of
> > > >         the
> > > >         MonoDevelop classes won't work without a properly
> initialized
> > > >         MonoDevelop runtime. So you must 'start' MonoDevelop to unit
> > > >         test them.
> > > >         It doesn't mean that you have to do it manually, and I don't
> > > >         see the
> > > >         reason why it could not be part of the build.
> > > >
> > > > Ok, so if I made some Test AddIn, I would like something like make
> > > > test to do something like this:
> > > >
> > > > 1. Build the test AddIn and copy it to the AddIn directory.
> > > > 2. Launch MonoDevelop.
> > > > 3. Execute the code in the Test AddIn.
> > > > 4. Quit MonoDevelop.
> > > >
> > > >
> > > > Is this possible to do automatically? I am thinking of step 3.
> > >
> > > Yes, all this can be done. Add-ins can define auto-start commands that
> > > are executed at MD startup. The only issue to be solved would be how
> to
> > > decide wether to run the tests or not, since if the addin is copied to
> > > the addins dir it will always be loaded, even when not wanting to run
> > > the test suite.
> >
> > Well, I would do it this way. Invoking make test should do the
> following:
> >
> > * Build everything as usual plus a special Test AddIn which is copied
> (along
> > with the other AddIns) to the AddIn directory
> > * Launch MonoDevelop
> > * The Test AddIn will then do its stuff
> > * Quit MonoDevelop (can the Test AddIn do this?)
> > * Remove the Test AddIn from the AddIn directory
> >
> > /Jacob
> >
> > > >
> > > >         >  Secondly it might be hard to test the internals of a
> class
> > > >         using only
> > > >         > some public API.
> > > >
> > > >         Mono has around 13000 unit tests, all of them using
> > > >         exclusively public
> > > >         API, so it's not so hard...
> > > >
> > > > Nope, it's not hard, we just need to find the right way to do it.
> :-)
> > > >
> > > >
> > > >         >
> > > >         > /Jacob
> > > >         >
> > > >         >
> > > >         >         Lluis.
> > > >         >
> > > >         >
> > > >         >
> > > >
> > > >         _______________________________________________
> > > >         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
> >
> >
> >
>
>
> --
> Rafael "Monoman" Teixeira
> ---------------------------------------
> I'm trying to become a "Rosh Gadol" before my own eyes.
> See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
> It hurts!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20051206/50b94eae/attachment-0001.html

More information about the Monodevelop-list mailing list