my idea to setup jenkins/hudson server so we can test it there
can TDD do this? F On Fri, May 20, 2011 at 4:38 PM, Miguel <mig...@almeida.at> wrote: > Hi Frans, > On Fri, 2011-05-20 at 14:52 +0700, Frans Thamura wrote: > >> >> and i have several question, and i think that is good if we can share it here >> >> i want to know, the test mechanisme , best practices of testing in Struts2 >> world >> > > I work in TDD, which means I write the tests first and then develop the > functionality (check Lasse Koskela's book on the subject). > > My usual methodology is: > > - Pick up a story/use case (eg: click on People list button shows the > list of all people in the phone book list) > - Write a Test class for the PeopleAction.list() method > - There will be a couple of tests: happy path, what if there aren't any > people, what if there's a problem accessing the database? > - Recently I've been developing a lot with services. this means the > action will usually be simple, something like manipulate the properties > that come from the request (if necessary) and pass them to the service > - The last sentence means I can mock up the service here: I am > interested in testing if the action behaves correctly - ie, if it > catches exceptions, sends to the correct result, I am not really > interested in knowing if the database is being accessed correctly. So > EasyMock is a good library to use > - After building the test and the Action, I do have the problem: is my > service (eg service.getAllPeople() ) working as expected? Time for some > integration test. Bare in mind I'm working in TDD: I've build an > interface for the service, but the implementation doesn't exist yet > - I repeat the test-build cycle, this time to build the correct > implementation of service.getAllPeople(). > - Work done > > Now, some remarks: > - This unit testing doesn't do struts integration, such as: > - Struts validation > - My custom authorisation (I have developed a @AuthorisedRoles > annotation that only authorised users with some roles to execute that > action > > I'm not really sure what/when/where is the best way to test this. Right > now I test this in a separate class that I suffix with, eg, > *ValidationIntegrationTest. I'm not 100% happy with this approach, as > a) I end up testing my action in 2 or 3 different places > b) I'm not completely happy with my validation test class yet, which > currently extends from StrutsSpringTestCase > > > Regards, > > Miguel Almeida > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
