Testing Tynamo application
Generally speaking, you can test your code at various different levels of granularity. The higher level the test is, the more ground the test typically covers (i.e. executes more lines of code), but the reasons for test failures often become more obscure. Lower-level unit tests are good for pinpointing exact problems but you need a lot of them to build comprehensive coverage over your whole code base. You can often divide your tests into a few different categories, such as unit tests, integration tests and functional tests. Maven has built-in support for executing both unit and integration tests and the Tynamo archetype takes advantage of it. In the archetype, the container-based test is thought to be an integration test and everything else a unit test. Tynamo uses TestNG because Tapestry uses TestNG but you can just as easily use the better known Java unit testing framework, JUnit. TestNG has a few handy things especially for integration testing, but JUnit 4 is roughly on par with TestNG feature-wise.
Unit testing your application
If you need to test helper operations of a page (class), you can simply instantiate the page and inject mocked-up dependencies as needed (use either Mockito, JMock or EasyMock), but Tapestry also provides a built-in PageTester class for unit testing your pages (see Tapestry's Unit testing pages or components guide). With PageTester, you can easily render the page and "click" on its links.
Services can be instantiated manually with mocked-up dependencies just as easily, but often times your services are dealing with persistence layer and you want to specifically test that your Hibernate criterias are working as expected. In that case, there's no substitute for testing against a real database. Fortunately, this is very simple with modern in-memory, embedded Java databases such as H2. Here's one example of a base class that you could use for testing your persistence services:
As you see, the base class will automatically try to roll back the active transaction at the end of the test. You can certainly open multiple transactions and commit them just as long as you properly clean up the modifications after the test execution so your changes won't collide with other tests.
tapestry-model-test contains a base class called AbstractContainerTest that is meant for container-based integration testing. The AbstractContainerTest starts up an embedded Jetty instance, runs your web application in place (i.e. picks up the templates from src/main/webapp) and uses the compiled classes in target/classes rather than building a war file) and initializes a HtmlUnit client for testing your page flow as if it was a real user. As a sample, Tynamo-archetype provides a working integration test that uses AbstractContainerTest.