On Thu, Apr 8, 2010 at 9:23 AM, Pere Villega <pere.vill...@enovation.ie> wrote: > Hi, > > if I may join the conversation (I submitted the Enovation code). IMHO the > approaches would be something like: > > 1) Unit testing. > > It's been mentioned to store these classes in a separate module (maybe I > misunderstood). I would advise against it, Maven 2 project structure (the one > used by Dspace) has a folder for testing (src/test) where one can put all > test-related resources. That includes Java classes, resources and other. This > can be used from Maven and other systems to run the tests.
This is really only best for use when you are actually able to run integration tests from Maven Builds, which is sufficient and observable in codebases such as dspace-services, where the codebase can be run/tested independently. But it is not a criteria when we are talking about regression testing. I already addressed this topic earlier in the thread. https://scm.dspace.org/svn/repo/modules/dspace-services/ > This tests are not supposed to be run by non-developers, and they should be in > the same module as the source they are testing. Absolutely true, another reason to be pushing for modularity and separating the build process out away from the installation process. Again we need to differentiate between integration tests and functional tests. Quite true, integration tests shouldn't be run by non-developers, but right now we are challenged that non-developers still run Maven (and Ant) to package a distribution, what we need is work done in creating an installation that is independent of Maven/Ant to install, but not platform specific. IE, we need something like the installer structure used by Atlassian's tools or Apache Sling. This was also discussed last year in the 2.0 development, but with lack of resources, work did not go forward. Per installers, we don't really need a bunch of different GUI based platform installers for DSpace, my fear is this will simple entrench the codebase even further than is now. What we need is a better architecture for deploying DSpace, we need an OSGi/SpringDM style solution for the distribution of DSpace. We need more adoption of standard Spring Framework and less hacking of custom solutions. In all actuality... I was pretty close to attaining this when we adopted using maven and rearchitected the build process. If you look at the build right now, what is generated by the Maven assembly process is a "Binary Distribution" that you install with Ant. If we only distributed that as the "binary" distro, we would have established a clean separation between build and deploy. Unfortunately, the reasoning for not doing so was that, in the community, there are so many customized dspace builds out there, usually customized in horribly intimate manners, that no one actually is able to just use a plain old binary distribution off the shelf... So, true, I'm not entirely happy with Scotts decision to embed his work into the existing ant build and local dspace install directory, but at this point its better to have something in place and continue the two discussions from there. Discussion (1) being about creating better installation with mechanisms for customization via theming and plugins. and (2) creating testing frameworks... > In this area, we have to be aware the code of Dspace is not really testable as > it violates the Law of Demeter quite often. I've read about the mock for > Context, which would make it easier to build some tests, but as I mentioned in > my JIRA ticket it would be advisable to consider some refactoring in the > medium-long term, to improve the quality of the code. In fact could eb done as > part of this year's GSOC now that 1.6 has been released. The sooner that's > done, less effort will be involved :) Focusing on utilizing the Spring Framework will bring us closer to not violating the Law of Demeter. We've already laid out a foundation for JUnit based integration with the dspace-services work that happened within the 2.0 development last year, you will find the testing libraries for dspace-services, for example here: https://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/test/java/org/dspace/servicemanager/ https://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/test/java/org/dspace/services/session/ > > 2) Functional/acceptance/regression testing. > > I completely agree with the proposal about using Selenium, in fact is probably > the best tool for the job and would be useful to validate a vanilla > installation of Dspace. > > The replacement of logic, as mentioned, should have little or no impact on the > scripts as they use ID or names to identify the actions, so even layout > changes should not affect them (in theory). Sure, this is great, but we have functioning code examples for Scotts work, the Selenium discussion that happened last year lead to no code AFAICS. Not only this, Selenium is about UI testing, its not going to spin up a DSpace instance for you. So yes, working on Selenium is a great idea, but it should always be one-off, much like Scotts testing framework should probably be one-off. But unless Scott or another is willing to do the effort to make it one-off/separate, we should accept what we can get now rather than derail development activity waiting for something better. A bird in the hand is worth two in the bush. > 3) Behaviour testing. > > Another aspect we could consider for Dspace is Behaviour Testing. As explained > here (http://blog.dannorth.net/introducing-bdd/) this could be considered an > extension of Unit Testing, focusing more on the expected behaviour of a class > than on creating test cases for each method. > > I find it more appealing to developers than unit testing, as you focus on the > functionality, which means less tests (as several times a number of methods > work together to achieve something) and reduced maintenance of unit tests when > you change methods). > > Given the status of Dspace, with a lot of code already done and several > dependencies among them, could be a way to provide testing for some classes. > And if you want to go all experimental, you could use specs > (http://code.google.com/p/specs/ for it, which offers some nice tools :) Something to consider in unit testing, sure... but I'm more for finally breaking those installation/db dependencies themselves... -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
