H Jean-Noël, i can only say, yes! Writing tests is a lot of work and some kind of good knowledge is needed to get the tests working in every case. But i'm afraid that qooxdoo does not offer any specialities for dependency injection. Maybe we can think together what could be useful and add those features to the framework?
Best, Martin P.S. Yes, just move the reference to the original function to a new one. :) Jean-Noël Rivasseau wrote: > > 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® 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-12, 2009. Register >> > now! >> > 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® 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-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://n2.nabble.com/Integration-tests-with-Qooxdoo-tp3651283p3661229.html Sent from the Q&A mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
