search

makumba / makumba

Makumba helps you rapidly develop data driven web applications. Provides a custom JSP taglib as a main interface, but leaves API open for advanced access. It is implemented in Java.
https://www.makumba.org
GNU Lesser General Public License v2.1
5 stars 2 forks source link

make the integration-tests self-contained #728

Open ghost opened 14 years ago

ghost commented 14 years ago

Reported by @manuelbernhardt on 20 Apr 2010 08:33 UTC it should be possible to run the integration tests (list-oql, forms-oql, ...) directly, in a self-contained manner, without having to start a tomcat instance by hand. this is needed for the continous integration set-up.

cargo (http://cargo.codehaus.org/) eases the deployment on a servlet container and provides a Java API and ANT tasks. I would go for using the Java API and have the deployment take place in the suite-wide setUp and tearDown.

Migrated-From: http://trac.makumba.org/ticket/1183

ghost commented 14 years ago

Comment by @cristianbogdan on 7 May 2010 08:31 UTC do we really need to adopt one more tool, can't we just deploy our webapps/test webapp on a tomcat?

like mak-test-webapp, Dynamic Web Project, dependent on Makumba, contains all jars it needs deployed to any tomcat 5.5. and tomcat 6 instance in Eclipse

both of the above (Dynamic web project, tomcat) are standard in eclipse.

then you start the normal list-oql or form-oql. i see absolutely no problem that they need a server to be started first.

this can be done more or less out of the box, without changing much code.

ghost commented 14 years ago

Comment by @manuelbernhardt on 7 May 2010 08:57 UTC the point is to make the tests run on ant (bug 1184) so that they can be ran by hudson. for this cargo offers the means to dynamically deploy on any container (not just tomcat, jetty), which comes in handy for testing and for this kind of deployment.

ghost commented 14 years ago

Comment by @rudolfmayer on 7 May 2010 09:55 UTC I personally don't care on what technology we use, but indeed it would be great to be able to run the tests:

So all in all, I am pretty fine to test the standard things in the eclipse setting, but I wouldn't want to click there also for jetty, maybe glassfish, and then HSQLDB and maybe SQLite, which would make nine possible combinations..

ghost commented 14 years ago

Comment by @cristianbogdan on 7 May 2010 14:19 UTC what we would need from cargo is to start a container and deploy an app. we know how to do that without cargo for tomcat. but it may be useful for other containers, especially the ant environment. but in eclipse it's good for eclipse to know about the servlet container because then you have debug and such.

cargo might take time to adopt, while starting tomcat (and maybe other containers) and deploying with ant file copy, we know how to do today. i'd suggest to start with that, and maybe continue with cargo.

comment 0:

it should be possible to run the integration tests (list-oql, forms-oql, ...) directly, in a self-contained manner, without having to start a tomcat instance by hand. this is needed for the continous integration set-up.

starting/stopping a tomcat instance can be done automatically from ant very easily. deploying to it can be done automatically from ant very easily.

i think the root problem is the weirdness of tomcat-mak, and we should get rid of that. which btw will get rid of a number of folders in the mak project: tomcat, tomcat6, maybe webapps....

about having to start a tomcat the first time you test.... hmmm... i do that every time i work with a makumba app too. i never saw a problem with it. do you think it causes an interruption of developer thoughts for the first time they run the tests? we can trigger it from testTomcat then. run a java application or ant target another process. platform independent.

also working with multiple projects in eclipse, especially when they are different kinds of applications (makumba is a library, test is a webapp etc) is absolutely no problem.

self-contained is an interesting goal. how about this

is that self-contained?

(In reply to comment #3)

  • with one click in eclipse, w/o needing to first start the tomcat

with a separate test webapp project you will start the tomcat once and then the mak changes will get deployed to it automatically

  • from the command line, independent of the eclipse launchers, so that you can check that the tests still work in a head environment checkout

as long as the tomcat is running (you can start it from ant easily and in a standard manner, not the way we do in tomcat-mak) you can easily deploy to it via ant file copy of a war or even by copy of a directory tree

  • on a different, dedicated database, i.e. with a different Makumba.conf. When I make a new feature, I normally fill my DB with the test data, to check whether the page works; then when I think it does, I make a test out of it, but then for running, I first need to delete my testdata, otherwise the test setup won't run.

yes the separate test/playground webapp will have its own makumba.conf. there is one already. or do you mean a different playground app/project where you can change Makumba.conf without affecting tests? sure, i fully support.

  • surely I subscribe to what manu described, being able to run the tests not only on a tomcat would be excellent.

WAR and webapp structure (WEB-INF, web.xml, classes, lib) can be deployed to any container. probably an ant file copy works on most containers

  • then there's also bug 1200, to run it on a different DB

yes, change the Makumba.conf automatically, redeploy, test.

So all in all, I am pretty fine to test the standard things in the eclipse setting, but I wouldn't want to click there also for jetty, maybe glassfish, and then HSQLDB and maybe SQLite, which would make nine possible combinations..

yes i guess that would be done by an ant script for you provided you tell it where the servlet container webapp dirs are. or by a loop in the test class...

ghost commented 14 years ago

Comment by @rudolfmayer on 7 May 2010 14:40 UTC (In reply to comment #4)

cargo might take time to adopt, while starting tomcat (and maybe other containers) and deploying with ant file copy, we know how to do today. i'd suggest to start with that, and maybe continue with cargo.

I think it is worth to check out cargo for a short while; if one can't figure out how it works in 30 minutes, indeed doing ant first is a good start.

self-contained is an interesting goal. how about this

  • ant starts tomcat
  • ant deploys webapps/test
  • ant runs list-oql
  • ant runs form-oql
  • ant stops tomcat

is that self-contained?

i would say yes

(In reply to comment #3)

  • with one click in eclipse, w/o needing to first start the tomcat

with a separate test webapp project you will start the tomcat once and then the mak changes will get deployed to it automatically

well, it is the same here.. still i need to first click on the run for tomcat mak, and then for the tests.

  • from the command line, independent of the eclipse launchers, so that you can check that the tests still work in a head environment checkout

as long as the tomcat is running (you can start it from ant easily and in a standard manner, not the way we do in tomcat-mak) you can easily deploy to it via ant file copy of a war or even by copy of a directory tree

well, not how our junit tests are working now, cause they are specific to the "makumba" project. so if i have a "makumba-head" project (i do :-)), i need to change all the launchers.

that's why an ant target that is totally out of the eclipse launchers would be great.

ghost commented 14 years ago

Comment by @manuelbernhardt on 7 May 2010 14:59 UTC there is an (old) article on cargo at http://www.ibm.com/developerworks/java/library/j-cq09266.html?ca=drs-

basically cargo does:

it also comes with ant tasks and such.

so I really think it makes no sense to re-do all the deployment game by hand when there is a library that does it all for you, on any kind of servlet container, with minimal effort (or, well, just the effort to copy-paste a few lines of code or of ant tasks).

whether or not to use ant tasks to trigger cargo or not, that I am not sure of yet. but my idea was to have the deployment done in the setUp() and tearDown() of the JUnit tests, so that when Hudson detects any kind of new test class in makumba (through JUnit 4 annotations) it will automatically run them without prior configuration. there is many more test suites than just lists and forms, and it would be good not to have to configure their execution each time one is added.

quick start at http://cargo.codehaus.org/Quick+start

I agree that tomcat-mak should probably be done in a cleaner way. what I would like to see first though if we need a standard webapp layout for cargo, or if it knows about the WTP layout.

ghost commented 14 years ago

Comment by @cristianbogdan on 7 May 2010 15:23 UTC i think there are several issues here: 1) how the developer runs tests in eclipse 2) how tests are ran automatically as an ant batch 3) how an individual test is discovered by hudson and ran (but can't hudson run all tests and then it's a matter of (2) ? do we really need to discover new individual tests?)

we should probably get an overall design that satisfies all these concerns

Manu would you like to make a Cargo proof of concept? i would suggest not to spend too long on it, since we can do many of these things with ant anyway. not as clean but still much better than tomcat-mak, and also in batch.

i would guess that (2) would have to use ant cargo and (1) would have to use java cargo but then if eclipse doesn't know about the tomcat process, will we be able to debug the test code?

it seems somehow that cargo doesn't fit with development and/or eclipse. but we can check the proof of concept for that :)

ghost commented 14 years ago

Comment by @cristianbogdan on 11 May 2010 13:16 UTC you can now do ant tomcat-mak your favourite tests tomcat-stop

same for tomcat6-mak.... tomcat6-stop

i think that's self contained enough. whether it can use cargo to fire the tomcat later on, is i think a secondary concern, the main goal (at least one of them) is achieved: automatic run from ant, for integration with hudson

if you want to change the database in between these tests, i think it's a matter of copying a Makumba.conf via ant, then fire the test again

if you want to change the servlet container, well i guess that's cargo unless there are known ant scripts that do it. but i think this is not so urgent of a requirement.

ghost commented 14 years ago

Comment by @cristianbogdan on 11 May 2010 13:21 UTC about the development situation. for non-cargo solutions, based on dynamic loading (the normal servlet deployment mechanism), see bug 1213

for a cargo solution during development. since cactus can fire any (?) servlet container via cargo, it looks interesting but i think we should set as a requirement that makumba is loaded through the webapp classloader (not through the static classloader) in that environment, and actually in any test environment, because that's how it's used in applications.

while in ant (so not during development) this is easy (make a war, copy it to WEB-INF/lib) during development in eclipse you would need to make the war behind the scenes and copy it before cactus starts the container via cargo.

ghost commented 13 years ago

Modified by @manuelbernhardt on 28 Jun 2010 07:22 UTC

ghost commented 13 years ago

Modified by @manuelbernhardt on 28 Jun 2010 07:24 UTC

ghost commented 13 years ago

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC