Hey Matt, On Tue, Mar 22, 2011 at 6:11 PM, Matt Madhavan <mattmadha...@gmail.com> wrote: > I'm creating the project structure/development/testing approach for my > client based on PAX mostly. I have couple questions. > For the OSGi bundles is even make sense to do Unit Test at all ? All the > bundles are tested from with in Integration tests anyway? But I feel that > for Persistence/business logic etc it might save development time if you do > straight unit testing instead. Does it even make sense to create unit test > cases for the bundles and test them outside of a container before you test > it inside a container (Itests)?
OK, I think there is no 100% best practice approach for this available. I've read a lot according to this topic and there are wide differences how ppl test and what they think is the best. But I can say what I do typically and with which approach I made good experiences: Typically I do not use any integration tests during "low-level" development, but rather the "typical" TDD approach. Write a unittest or a mock, "define" what the service/interface has to do and implement the real code. That way you're way faster than using integration tests or doing a manual "startup and test everything" approach. If you get handy with this approach and use e.g. wicket for your frontend you can even implement ways of your UI logic (row components and logic, without any fancy UI ;)) without ever kicking up felix/equinox/jetty/... So, but when do you (or at least when do I) use integration tests. Integration tests are typically a slow thing. Although pax-exam speeds up the process a lot (compared to manual testing) still it requires way more time than simple, plain old unit tests. OK, back to the base question what to test now via pax-exam: Everything you cant test (easily) using unit tests. Good examples are: wiring (via e.g. blueprint or spring), if everything starts up correctly (webserver/jetty/webapp), if the webside is displayed correctly, are the services deployed and wired correctly. Basically everything I would let do a manual tester. I won't let a tester check if my math-function behind interface X does what it should do. That's what I've validated by using unit-tests. But I would let him check if all bundles are started and wired (this is actually one of my standard integration tests), if I can reach the webpage, login and do some more or less complex tasks against the UI integrating most of the code at once. But I'll definitely not test everything (damnd I want to start the itests, go for a coffeebreak (after 1-2 hours hard-core-unit-test-validation-hacking) and see if everything is still green) (this can also be done by e.g. Hudson). Ok after I've told my story I think everything I know and have experienced about testing in OSGi environments is already said. But I'll try to sum it up again: * Don't try to test e.g. blueprint injection on bundle level. This is way to slow for real use. Instead ignore it and mock the behavior using mocks. * Test more than one thing in your integration test environment. The environment requires time to come up and go down and you want to cover as much as possible of your application within the least integration tests you can manage. * Check if you all your bundles are up and wired. This is quite an easy test (iterating all bundles for their state and checking if they export their blueprint services correctly but should show if all your bundles are correctly wired at least. * Check huge, tricky complete usecases covering as much of your system as possible. Those tests should check if the entire logic still works as expected/defined by your use case. Those tests should give you confident that most of your system is still completely usable * Always keep in mind that you (should) have already a extremly high test coverage using mocks and plain old unit tests. Integration tests are there to verify if your system as a whole still works and if all the external systems still play well with it, not if your internal logic still works (again the unittests :)) * Avoid the need to test every usecase, every button and every service again in an integration test. This leads to test suites requiring 12 hours (Its terrible I know, but I actually know companies having such suites). In such suite you start writing almost integration tests only (the devs think: y should I duplicate those tests) but 12 hours is WAY TOO LONG to get any useful feedback cycle... > If unit testing is OK then for BluePrint bundles how do I load the regular > beans from the blueprint.xml file like I would load spring.xml file via as a > classpathapplication context? Ok, I think I should have answered that before already :) I hope my feedback helps you in deciding which road to go with pax-exam, unit-tests and all that stuff. But please always keep in mind that this is my personal opinion and there are LOTs of books out there praying a different point of view (some even the same ;)). So feel free to test more than one option and choose the one you and your team are most confident with. Kind regards, Andreas > Any ideas please? > Thanks in advance! > Matt > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
