Stephan Schwab

Software development and farm life

Archive for December 2006

[TSE] Meeting Requirements through Acceptance and Stress Testing

leave a comment »

My fellow German developer Eberhard Wolff is speaking this morning about acceptance and stress testing to meet requirements.

As an introduction he’s wrapping up what Spring provides in the org.springframework.test package.

Acceptance Tests

Now we are getting into Acceptance Tests. You use them to find errors in the implementation of business requirements or use cases. One can see them as formalized requirements. Unfortunately many times they are done manually and after the whole system has been developed. Fit/FitNesse is a tool for acceptance tests. The customer and the developer should write the acceptance tests together – so does XP say. Fit/FitNesse uses HTML as input format. Test data and expected results are provided as HTML tables. You need to write a simple class as a wrapper for business logic, which can be injected using @Configurable. This class is then used to pass data into the test and check the results.

Eberhard is working on a general Fit Exporter for Spring. It’s currently Alpha code.

The SpringActionFixture can be used to test actions that are usually performed in a GUI. You specify input data and actions – e.g. press add button – and then look for results. In the HTML input file you use the expression “press” to call a method. So the UI stuff is left out, but the method that normally be called by the UI is now being called by FitNesse.

One question from the audience is whether you can run Fit/Fitnesse as part of a Maven build. As it’s a command line tool that should be no problem.

Fit uses HTML files as input. Fitnesse uses Wiki pages. Triggered by a question from the audience Eberhard opinions that probably Word documents that get exported to HTML are the best solution to get business people to provide test data and rules.

Performance Tests

JMeter is a good tool to performance test web based applications. JMeter creates a large number of requests, but how do you measure the performance in the whole system. You want to measure each part of the system. Using a regular profiler for Java would not be sufficient for the purpose of performance tests, because it only focuses on the Java code itself. JAMon is a monitoring framework, which offers a Spring interceptor. For web application you configure a filter in web.xml. The JAMon filter measures HTTP request/response. JAMon profiles method calls using AOP. JAMon can be used as well to profile other parts of the system by simply declaring other AOP aspects, e.g. you could use it to profile SQL queries.

One could use JAMon even in production as the overhead is very little. It can use exiting Pointcuts and Spring AOP proxies.

Written by Stephan Schwab

December 10, 2006 at 1:57 pm

[TSE] System Integration Testing with Spring

leave a comment »

Fixing defects at a late stage in a project is more costly and causes more pain than doing it as early as possible.

Testable code is good code. Testing is essential to agile processes. AOP helps to isolate concerns. Infrastructure can be left out of the business logic and hence makes testing the business logic easier or – in some cases – possible.

Developers should take ownership of unit and integration tests and not rely on a QA function. A QA function is still needed, but developers should start testing while writing code. Many developers don’t test the UI, which is bad. JWebUnit can help with that for web applications.

Rod stresses the importance of performance assurance and regression testing. The Grinder is a free tool for load testing.

Unit testing. Don’t use Spring in a unit test. Do use mocks or stubs. Unit tests should run extremely fast. With mock objects you can create expectations. See Easymock or Mockobjects. Mock objects are great for service layer objects and domain objects and to test what happens in the event of a failure. A few things that make testing hard: static methods, final classes. You can’t test in isolation: configuration, JDBC code or O/M mapping and how classes work together.

Artifacts to test: service layer, domain objects, special cases such as aspects, web tier code, code containing SQL or other queries and code interacting with J2EE APIs. Non-Java code like stored procedures or triggers, database schema and views. O/R mappings, Spring configuration, JSPs and other view technologies. With Velocity you can test the without being tied to a container.

In-Container testing with tools like Cactus is not the answer.

Spring helps with the org.springframework.test package available in spring-mock.jar since Spring 1.1.1. Provides Spring context loading and caching, transaction management and – of course – dependency injection.

Put things like the datasource and transaction manager declaration in configuration files of their own so you can use different ones for testing and production use.

If you are on Java5 use AbstractAnnotationAwareTransactionalTests for tests.

Use the JDBCTemplate exposed by the abstract classes to verify that the O/RM tool did what it’s supposed to do.

Test lazy loading with endTransaction()

startNewTransaction() to test attach/detach in an ORM tool (merge() or saveOrUpdate()). Test locking strategies.

Written by Stephan Schwab

December 9, 2006 at 4:43 pm

[TSE] The Art of Domain Modeling

leave a comment »

Now at the beginning of the afternoon it’s Keith Donald’s second talk about Domain Driven Design at The Spring Experience.

Effective modeling is about creating a knowledge rich model with everything relevant to the problem being solved. In order to achieve this one has to develop a common language so that everybody involved has a chance to stay on the same page. It’s about brainstorming and experimenting using tools such as unit tests and the IDE. The idea is to write code very early, but for the time being leave questions of the infrastructure out.

Domain experts and developers need to work together. Only I believe that most domain experts don’t have the time to follow that approach. So in the end it will be about showing a simplistic prototype to them. Something that appears to be working, although underneath there is no functionality that can really be put into production. I see a few questions here.

Once you understand enough of the domain problem, write some code. Focus on behavior, avoid all infrastructure. Then get some feedback from users. Again I see some questions here. The idea is certainly a good one, but will the users accept being shown something that is purely a simulation? Some non-technical people tend to expect real working software dealing with real data at an early stage. So here will be certainly some need to explain things to them.

Written by Stephan Schwab

December 8, 2006 at 7:23 pm

Follow

Get every new post delivered to your Inbox.

Join 258 other followers