Hear, hear. Couldn't agree more. On 12/02/2010, at 7:36 PM, Howard Lewis Ship wrote:
> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
