Accueil > Non classé > How we have the development specific code safely out of the way

How we have the development specific code safely out of the way

Quite frequently, one has to write some development specific code. For example, at work, we have, when needed, an « application launcher » (named with the application name) and a dev web page, mounted under /dev. This page in turn allows to write shortcuts in the application work flow, in order to access specific page with an ad hoc environment (profile, data…).

However, one quickly wonders how to be sure these classes won’t get in production.

Our solution is linked to m2eclipse. This maven plugin for eclipse has the following behavior : it puts both the main and test source paths in the class path. As such, one can access both the production and test code when running the application from eclipse. This is normally not done by Maven. More precisely, Maven build jars don’t include the test code.

The solution is then really easy : we put our dev. specific code under the test branch, and we are perfectly able to run it all from eclipse. But Maven makes sure none of it will make it into the production jar/code. Double with this application launcher + dev page conventions, it really makes it simple to dig into an application/project. Nice and easy no ?

Publicités
Étiquettes : , , ,
  1. septembre 20, 2009 à 5:35

    I think it’s not a good idea to merge application- and testcodein that way … maybe a « team-newbie » create a dependency between application and test-code (test-code to application-code is the normale way).

    I had done this 🙂 Inside eclipse all seams to working (tests are runing successfuly) but then on the buildsystem a errors happend. Why? Sometime it’s hard to find such kind of failure.

    I think such « debugging » code is real code and should not be part of the test-code. There are other options to ensure that such code is not part of the live-application (e.g. aop, different spring-configuration, assembly, maven-profiles …)

    regards
    andreas

  2. Joseph Pachod
    septembre 23, 2009 à 8:16

    thanks for the comment 🙂

    up to now, we didn’t had any issue with test code to prod code dependency.

    However, I think it’s due in part to Wicket’s nature : it’s really easy to have a « stand alone » page which is still mounted and interact with the rest of the world. It’s not like we had to think or care about it, wicket just makes it really simple.

    Furthermore, we use hudson for continuous integration, so the feedback would be pretty fast.

    In the end, I don’t see how you would want such code to be « more » independent of the « live application ». Putting this dev. code in the test folder makes sure it won’t go in production. What would you suggest here ?

  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :