Re^2: A better way to see module changes in a running web server

From your post I've got a feeling that you're not TDD addict and that you're doing development directly on production server (or why else to bother about performance).

I think perhaps you misunderstood the OP.

TDD is great but when developing a web application you also need to test out your application in the browser as you develop. Relying completely on TDD for this type of thing is a recipe for disaster, you *always* need to do some real-world user testing as well.

Secondly, I highly doubt the OP is developing on the production server. I would suspect he is talking about developing on a local mod_perl enabled development server. His concerns about performance are valid since often times with mod_perl apps there is a lot being pre-loaded and startup can take a while. In cases like this a long startup delay can really slow down the development process, especially if the restart is unnecessary.

-stvn

Comment on Re^2: A better way to see module changes in a running web server

Replies are listed 'Best First'.
Re^3: A better way to see module changes in a running web server by swartz (Beadle) on Sep 14, 2009 at 21:17 UTC
stvn is correct - I was talking about a development server. I've made a small update to the post to clarify. And I certainly do care about my development environment's performance. Repeated restarts not only take up time, but just make development more frustrating.	[reply]
Re^3: A better way to see module changes in a running web server by zwon (Abbot) on Sep 12, 2009 at 23:09 UTC
when developing a web application you also need to test out your application in the browser as you develop. Yes, but that's a view part, and there's usually no need to restart webserver if you're making changes in templates.	[reply]
Re^4: A better way to see module changes in a running web server by stvn (Monsignor) on Sep 13, 2009 at 00:17 UTC
Yes, but that's a view part, and there's usually no need to restart webserver if you're making changes in templates. That is an oversimplification since the view is not just the template but also the parts of the controller that is coupled to the view (in Catalyst this is the stash, most other systems have something similar). When your controller code changes then you will need to restart the server in order to force the recompile. Not testing your models and controllers (assuming your doing some form of variant of MVC) within the context of the running web application and from a users point of view, is just irresponsible. You can test your models and your controllers using TDD, you can even test your views using TDD (Test::WWW:Mechanize, Selenium and the like), but these are tests in controlled environments following specific pathways. User Acceptance style testing should not just be done at the end, but should be done all the way through the build. It is important to know your application runs well out in the wild on a real server with real concurrency and real users using real browsers. To not do so would be just foolish and asking for trouble, remember that tests cant prove the absence of bugs. -stvn	[reply]