HI Andreas, Thanks for the reply - very valuable and I really appreciate it!
Have one more questions though! How can I load beans from a blueprint.xml file like the way I would load beans from a spring config file (say like a class path application context - BeanFactory etc). If I do want to Unit Test, I may create just the beans using blueprint.xml (No Service etc) and lookup the bean by name and do my plain unit test. I do not want to introduce spring on top of blueprint just because I want to to plain unit testing. In nut shell i want to define bunch of beans and load them programatically at rune time and perform bunch of unit (plain) test. Any help or guidance to this will be appreciated! Thanks in advance! Matt On Tue, Mar 22, 2011 at 3:13 PM, Andreas Pieber <[email protected]> wrote: > Hey Matt, > > On Tue, Mar 22, 2011 at 6:11 PM, Matt Madhavan <[email protected]> > 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 > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
