Hello Martin,

thanks for this very enlightening reply. I agree with you saying that if we
want to go the TDD route, we should also code with that in mind.

But in that case, I really think we need a powerful Dependency Injection /
Inversion of Control framework. Although I am not (yet :) an expert on the
subject, it seems to me DI / IoC is very useful for unit / integration tests
as it greatly eases the injection of mock objects into the different classes
under tests, which is absolutely mandatory (I mean, you need to mock stuff
if you want to test in the unit way).

So my question is, what can Qooxdoo offer in this area? On the server side
we use Spring (which I love) which indeed offers powerful dependency
injection. It would be very nice if Qooxdoo was able to help with this as
well on the client side.

Without help from Qooxdoo part, I fear that writing useful unit tests will
be *a lot* of work, because so much boilerplate code will have to be written
manually to create mocks and inject them. Not to mention that this means we
will have to port our legacy code, but this is not necessarily a bad thing.

So, I hope this discussion will continue with insight from other people
doing tests on the client side.

Jean-Noel

PS: on the subject of the method you mention. How do you "patch" a function
in JavaScript? I think you just erase the function object and replace it,
right?



On Wed, Sep 16, 2009 at 8:54 AM, MartinWittemann
<[email protected]>wrote:

>
> Hello Jean-Noël,
>
> first of all, congratulation to your step of using TDD. I am a big fan of
> it
> and it really works for me in the most cases. But keep in mind that TDD is
> using unit-tests and writing code which is testable in unit tests. So
> perhaps you can use more Mockups for testing, especially in a MVC
> architecture. You can always have a look at the framework tests to get some
> ideas like the new FormRendere tests (qx.test.ui.form.FormManager) where i
> recently used a mockup for testing.
>
> That your application is using the qx.core.Init.getApplication() a lot is
> really not good for testing because thats like the use of a static variable
> or static class. You can not test without it which makes it hard to test
> things in a smaller scope which you should in a unit test. One idea to get
> it testable is to replace all the calls of qx.core.Init.getApplication()
> with a factory method which returns exactly what you need.
> getApp : function() {
>  return qx.core.Init.getApplication();
> }
>
> If your code uses your own method all the time, you can easily patch it
> with
> some kind of mock you need in that special test. But that should just be a
> way to get your legacy code testable. If you write new code and need
> something like this, maybe you should think of a better architecture for
> the
> new parts.
>
> Another good tip for you is to take a look at qx.test.ui.LayoutTestCase.
> Its
> a subclass of our regular unit test and extends the test scenario with
> commonly used methods in the field of layout testing like the getRoot()
> method which you sure need in some cases.
>
> Best,
> Martin
>
>
> Jean-Noël Rivasseau wrote:
> >
> > Hi team,
> >
> > I am currently looking for some advice about testing for our Qooxdoo
> apps.
> > We would like to switch to a Test Driven Development methodology, thus we
> > are investigating our options.
> >
> > The main problem I am encountering is that I feel writing unit tests for
> > our
> > application is hard and/or useless. Eg, testing classes one at a time has
> > not much interest; we use a MVC architecture, and there are very few
> > things
> > that can be tested individually (eg, for a single class).
> >
> > Most of our tests should be so called "integration tests", where we
> create
> > a
> > lot of different objects and test the interactions between them. For
> > instance I register a listener, and I test that if the action is taken,
> > the
> > correct callback takes place. So I've started trying to write integration
> > tests within the base TestRunner Qooxdoo framework. But I went into
> > troubles
> > immediately. In particular, our code quite often calls
> > qx.core.Init.getApplication(); but when I run this in the TestRunner, the
> > object that I get is the TestRunner instance, and thus all my code fails
> > instantly...
> >
> > It seems to me TestRunner may be useful for testing Qx as a framework,
> > since
> > unit tests are much more easier for a framework. But I fail to see how it
> > can help me write integration tests, although I really wish to...
> >
> > I have used Selenium in the past for functional testing (eg, tests in
> real
> > production situation) and this worked very well. I could (and will
> > actually)
> > use Selenium with Qooxdoo for such functional testing, but in order to
> > switch to a TDD, I also need to write integration / unit tests and
> > Selenium
> > is a bit too high level for that.
> >
> > Anyone has advice for our team? Can the qx.core.Init.getApplication()
> > problem get fixed somehow (via mocking or...)?
> >
> > Thanks
> >
> > Jean-Noel
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to