Archive for December 2006
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.
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.
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.
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.
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.
Keith Donald’s talk at The Spring Experience has started. Right now he’s summarizing what Eric told us before.
A domain model does not capture every aspect of the real world. Instead it’s a simplistic view of the world to serve a purpose. Discoveries during the implementation feed back into the model design.
Isolate the domain by using a layered architecture. Do not mix UI, database, external services and business objects all together. The very same isolation allows unit testing and Spring helps in the wiring of the units.
Keith shows a diagram with the user interface on top of the application and the application on top of the domain and everything on top of the infrastructure. The application layer delegates tasks to the domain layer for complex solutions.
The domain layer represents business rules and states.
The infrastructure layer interacts with the database, constructs UI widgets and deal with everything technical.
The domain layer is to isolate the domain objects from other functions in the system to avoid mixing technical and domain concepts. One should bind the model the implementation early. Implement the behavior of the application within the domain model classes without thinking about the technical infrastructure. The resulting artifact is a unit test.
In the beginning map domain entities literally to Java objects. Some of these mappings may be wrong in the end and you will need to refactor, but it’s a start. Then start writing unit tests using those classes. Keith is now showing actual code of unit tests for his reward dining example.
Organize domain behaviors into coarse-grain, high-level user operations. Make user operations part of the application layer. Unit tests in the domain layer are a good place to look for application layer use-cases. The application layer encapsulates complex domain layer objects and rules and allows for freedom in the implementation. After defining the boundaries of the application layer focus on streamlining the domain model implementation.
Streamline associations between model objects. If you don’t understand why an association is needed, avoid it. Association create coupling, which is generally to be avoided. Impose a traversal direction on associations.
Entities, value objects and services. Often entities are persisted to a database. Entities maintain their identity that never changes. Entities may be used by other applications and need to be tracked. They have a life cycle and the model needs to define what it means to be the same thing. String entity objects down to the most intrinsic characteristics and only add required behavior and attributes needed for that behavior. For everything else add associated objects.
Value objects are identified by their attributes and often they are interchangeable and transient. Value objects can be shared and are good candidates for immutability. They reduce bugs by avoiding invariants.
Services are activities or actions, not a thing. A service is something that makes it happen and is stateless. Services should be thin coordinators and one should resist the urge to develop fat services that attempt to solve the problem all on their own. Look for natural opportunities to encapsulate behavior in services that doesn’t make sense within Entities or Value Objects. The main responsibility of a service is to orchestrate things, to coordinate. It delegates to entities to do the work.
The creation of Entities should be done using factories and repositories that restore an entity object from a persistent form. Services control and coordinate the life cycle of entities.
Someone asked whether a repository isn’t a service. Keith answers is that a repository is a DAO service, but with a very simple job. It doesn’t coordinate work and therefore it wouldn’t be justified to call it a service.
Make sure that your factories and repositories return fully initialized objects to their callers.
I’m sitting in Eric Evans’ talk “Introduction to Domain Driven Design” at The Spring Experience. The first question he is asking is whether your problem really is a technical problem. Technical people tend to see everything as a technical problem and seek technical solutions to solve it.
Understanding the problem domain better is key he is saying. I agree, but let’s see how DDD can help with that.
Be careful not to mix your opinion or perception into the creation of your model. Be precise in your model. Avoid shortcuts and don’t assume that details are already well-known.
Probably even very small projects will use multiple data models to help in the implementation of the solution. Objects created to deal with one model should not be taken out of context. This raises the need to convert information between the models.
Eric goes on saying that one should not try to come up with a big, every encompassing enterprise domain model, but instead a model for each part of the system. Frequently great object designs get modified so many times that in the end the original architecture will not be there anymore. It seems he proposes to isolate concerns, create the best model for a well defined part of the system and then find a way to interface those parts with each other.
Interesting: modeling does not drive an upfront design phase. In fact it would be wrong, because at the beginning of a project the team is ignorant about the problem domain. Trying to come up with a model at that stage will create the wrong thing.
Not tools like visual programming, UML diagrams and so on help to raise the needed level of abstraction. Instead proper use of language as the primary abstraction tool is important. Eric’s favorite modeling tools are: whiteboard, IDE, unit tests to explore the model itself and, again, our mouths and ears.
Next week I’ll board the plane from Panama City to Miami to attend The Spring Experience in Fort Lauderdale.
These are my picks from the various tracks.
- An Introduction to Domain-Driven Design
- The Building Blocks of Domain-Driven Design
- Using Dynamic Languages with Spring
- Code Organization Guidelines for Large Systems
- Spring (Acegi) Security with Ben Alex
- Applying Domain-Driven Design in the Enterprise with AspectJ
- System Integration Testing with Spring
- Beyond Low-Hanging Fruit: Domain Object Access Control
- Myth Buster: Spring is XML Hell!
- Rapid Fire Session – Terracotta for Spring
- Meeting Requirements through Acceptance and Stress Testing
- Real World Rules Engines – Why You Should Care
- Spring, Hibernate, and JDBC Integration Patterns
I hope to bring back a lot of inspiration for my current project and my team here in Panama. Domain-Driven Design sounds quite interesting. Of course I can’t miss the session about Spring Acegi Security as I’ve started to write a book about this topic.