I like to be test driven, but there's a few issues here: - Test First vs. Test Driven .... I often prefer to get the code "close" then think about testing - HQL testing is *integration*
Testing HQL is integration between the application and the database, you can mock all you like with no assurance that your tests have any basis in the reality of your database schema and contents, so a single integration tests is worth far more than a dozen unit tests. On Thu, Feb 11, 2010 at 11:22 PM, Igor Drobiazko <igor.drobia...@gmail.com> wrote: > Dear Vangel, > > I encourage you to read Joel's article on testing the software. > > http://www.joelonsoftware.com/articles/fog0000000067.html > > The value of reloadable service is questionable. If you write tests you > don't have to start the application at all if you are fixing bugs in > services. The cycle of fixing bugs in services is much, much shorter if you > write tests. You change a line of code, click the "Test" button in your IDE > and see the results of the test immediately. You don't have to switch to > browser, reload the page, etc. > > > On Fri, Feb 12, 2010 at 12:27 AM, Vangel V. Ajanovski <a...@ii.edu.mk>wrote: > >> On 11.02.2010 23:17, Howard wrote: >> > You wouldn't be able to change service interfaces this way, or module >> > classes (including contributions and the like) ... but changing a >> > service implementation should be a snap. This would especially be >> > useful for DAOs while creating and tuning database queries. >> > >> In our project 90% of all bugs were either in page classes or in DAO >> implementation classes (bad queries, queries returning nulls, queries >> returning more than a single row etc). The former are reloadable, the >> latter not. So if we would be able to change the DAO impl. classes while >> developping it would speed things up by at least 50%. >> >> In fact we rarely have the need to change the interface of a service. It >> is usually that we were wrong in the insides of the code behind. >> >> Some of the bugs were detected when we went in production and the >> application was under pressure by real users because we didn't have time >> for proper testing. I had to restart the whole application many times >> during peak load, and sometimes even the entire Tomcat service just for >> a simple change of a constant in a query that was only reflected in a >> single web page. >> >> I know that I should test first, and I know that I should enforce some >> QA before going in production for any serious application. But sometimes >> you just don't have the time and resources to do it, and RAD via many >> prototypes and fixing code on the fly is the best you can do. >> >> So I would urge for any type of fix - even a quick fix/patch, not a full >> release, even if it would only help in a very constrained case - for >> example only in the case of dao implementation classes and only when no >> modification is done to class properties and method signatures. >> >> >> >> > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de/blog > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
