JavaRebel impressions – Java Reload just like in Rails

So the reason why you often need to restart and see the results on the screen is because you do manual testing on the screen rather than automated tests? When I develop j2ee apps I rarely need to do slow restarts of the application server as I test my components outside the webapp! When I develop my Super CSV reader/writer (http://supercsv.sourceforge.net/), I do not check the files it produces, I let Junit do all the tedious and repetitive work for me.

Finally, what happens if you are doing a change across several classes? how do you ensure that you do not refresh a class that does not fully work, as it rely on methods in other classes working in a different manner than they presently do (you haven’t yet edited those files).

Hope to hear your input..

Hi Kasper,

there are several answers to your post.

First I agree with you, JUnit tests are a good thing to have and if you can develop functionality with them and don’t need to start an app container, good for you.

Second. Sometimes it’s very hard to do unit testing. Either your application is a legacy application with some nasty habbits (Singletons, static attributes, no dependecy injection, not enough layering), your build enviroment has no provision for junit tests or your organisation doesn’t do unit tests.

Third. You need to do GUI development. I have the habbit of encapsualting most of the mapping of business logic (user is logged in) to GUI logic (show menu) into editors or other Java adapter classes. It’s a lot of work to test those, especially if you’re exploring the GUI portion to try out what works and what doesn’t. Contrary to the case where you know from the beginning how your app should look. Some CSS and HTML problems are besten solved by trying and not by specifying the HTML/CSS result.

Fourth. Testing some integration stuff is diffucult to test with Junit tests. You can test them with “manual inspection” or with some other testing method (functional tests, integration tests, test replays, FIT, …). If you can’t do those other methods (which sometimes are more difficult to run than the app server, so no time is saved) then your back to starting your container and see what it does.

Changing several classes is no problem, as far as I can see. If I save my file in Eclipse, then it’s saved and compiled. With unit tests you also need to save all files to get them compiled. If you haven’t edited the other classes, then your unit tests won’t work either.

I wrote something about testing class with static attributes here. And I’m always interesting how to test nasty legacy code.

Hi Stephan.

Thanks for your reply. I am still a bit confused about your answer in the context of your blog which deals with tomcat (and thus presumably web applications). Let’s go through it step by step.

Your second statement (in your reply) is that you find it difficult to junit test legacy applications.. what do you define as a legacy application? And why would such an application need to be executed in a tomcat environment?

Your third statement is about GUI applications. Again, I’m not sure you need application servers or tomcat for such applications.

It seems like you mostly want the dynamic class-reloading because you are in an environment where you do not separate concerns. And rather than fixing this problem, you go ahead and do manual verification of each and every functionality of your system rather than taking the time to refactor out the stuff that doesn’t belong in your view (whether it be JSP or SWING).

It strikes me as odd to promote such practices by blogging about it. Wouldn’t it be better to resent this hacky tactic of testing and promote automated testing and good solid practices instead?

-K

2.) A legacy application is one which has a grown code base and is several years old. Usually several 100k lines of code. When this application has a servlet part, it is usually executed within tomcat. Those applications are often not designed for unit tests and have singletons, not enough layers, methods that do too much and static attributes which all together make unit testing very hard.

3.) “… rather than fixing it.” Fixing a problem for an application with several hundred developers and millions of lines of code can be a hard thing. I came across several such applications during my consultant days. It costs several hundred thousand dollars to refactor such an application. Someone has to pay them.

“… you go ahead and do manual verification of each and every functionality of your system …” Didn’t say that. As I said you can use test tools, FIT or other ways to not manually test those parts. But still you need to reload the application in Tomcat.

And when you migrate to junit tests – which sooner or later you should – you still need to run manual tests because migrating several million lines of code to junit tests will not happen in several days. For the time you either do manual testing (or use the tools see above) or no testing at all.

Have you successfully refactored a several million line of code application to TDD? What have your experiences been? What can I learn from you? Did you blog about it?

Thanks
-stephan

touche

hi stephan,

which open source project was it that qualified for JavaRebel ?

thank you,

BR,
~A