Is there any relation between DOM and Strategy Pattern?

[DistillingSpring]

I have to confess that I didn't research that much, but in the ones that I did here in the Forum, I couldn't find out about relation between DOM (Domain Object Model) and Strategy Pattern (or any other pattern), if any. Do you have a good link about it?

Thanks.

[DistillingSpring]

By the way, I am asking because I just finished what's suppose to be our domain objects and the first activity after was to define the patterns to apply and we decided by the Strategy pattern, for many reasons. One of them is that it's pretty reasonable to use together with Spring. So, is that a good approach?

[wpoitras]

I don't think you want to "apply" a pattern here. Figure out what the problem you are trying to solve, and see if there is a pattern that fits. Or adapt a pattern to your problem.

Now that you have defined your domain objects, what needs implementing next? Since you are still at the domain layer, it would be a good time to define your unit and/or integration tests. IMO involing Spring until testing is further along is premature.

Unless of course you've already written your tests.

[Marten Deinum]

I'm with wpoitras. Patterns need to solve a problem or help solve a problem. If at the moment you don't have a problem, then don't start to add a pattern just because it sounds/looks neat. Make sure it solves a real (business) problem/requirement.

[DistillingSpring]

Thanks for the answers. Actually, I already applied the strategy pattern because it was feasible to our problem up to now. It's a conversion from a procedural language to Java and we know very well the problem we are going to face. Then, I agree with both of you but I would like to know more about the relation between the "new concept" of DOM against the patterns concepts. The last one I am handling pretty well, IMHO. If I identify a pattern in the moment of the domain design, can I apply a pattern already?

Now that you have defined your domain objects, what needs implementing next? Since you are still at the domain layer, it would be a good time to define your unit and/or integration tests. IMO involing Spring until testing is further along is premature.

Unless of course you've already written your tests.

It was a very good suggestion about the unit tests. Do you have a simple example from your own experience on how to define unit test after defined domain object model?

I also have written my tests, but not with JUnit or Mocks yet.

Thanks again.

[wpoitras]

how to define unit test after defined domain object model

Simple, I don't wait until after. Actually I haven't been able to use Domain Driven Design on my projects. Most of my testing is on stateless services. But the principle is the same.

Your requirements are your best guide. Think about the operations on your domain objects. How do you know they will work? You test them. I would do an internet search for "test driven design". The interesting thing is the testing can drive the design of your objects because the tests are real usage of your objects which can produce real problems or show the right pattern or abstraction.

Since you have already started writing tests the questions to ask:
- Do they cover everything that could break? Trivial code (like getters/setters) can't break. But code with logic (even simple logic) can.
- Are they 100% automated? Can you run them in a test suite? This is where JUnit tends to come in. JUnit (and similar frameworks) give structure to allow all your tests to follow the same recipe.
- Are they fast enough you can run them as often as you want? Some integration tests take a long time. Those might run in an overnight suite. But all your unit tests should be fast enough to run during the say. And a lot of your smaller integration tests as well.

The most important thing to remember about writing tests, particularly when you have a lot of code that isn't covered by tests: Concentrate in areas where the tests increase your productivity immediately. Development is a combination of writing, testing and debugging code. When I use test driven design, I tend to do a lot more writing code which also tends to spill into testing. And my debugging is much faster because I don't need to deploy my code to a server (which in my project is a huge deal).

When dealing with existing code I tend to write tests when someone reports a bug or I refactor code. But not until. That is because writing tests for existing code that works is just writing tests for their own sake. There might be some benefit. But its often not immediate ("Gee, the 1000 tests I just wrote says the code which has worked for 3 years, still works".)

[DistillingSpring]

So useful information. Thanks a lot. Up to now, my tests are only making sure that my DAOs are working. So, I am testing meanwhile I am validating my model, which I know is not the best way, but I still can do the refactoring, even if it means throw all this away. I have been playing with JUnit and I know how useful is this tool. However, in my case I really need to hit the database now! Why?! Boss's requirements! He wants to see something real as soon as I can develop. I guess that I also could use some of the test APIs of the Spring for that. I also totally agree that I have to test the business logic and not getters/ setters, but your point on that makes me keep my flag about it even higher. Again, it's a conversion of a legacy system and we know in advance what should be the expected results. The work now is put all these in unit and integration tests. Thanks to share your real-world experience.

[wpoitras]

Integration testing can be very important in a system where the database plays a large role in the business logic. This is certainly the case in my system. Our "business objects" are really just thin data holders and most of the logic is in the database. I just finished a large project and most of my testing efforts was spent in my integration tests which called a live database. I had made sure the stateless services that invoke the database were sufficiently decoupled to be able to integration test them as well as function in an application server.

The only place I was able to do much unit testing was in the validation objects we use for our field level validation. And only for the new ones I developed.

Spring was a big help for me to develop my integration test base classes. Our system has at least 3 database they talk to, so I had to make it flexible to load datasources from one of 3 databases. So I know the kind of thing you are up against.

[DistillingSpring]

I know I can research by myself, but would you mind to say how did you apply your integration test and how did you use Spring for that? Did you use the "Chapter 23. Testing" of the Spring's reference?

[wpoitras]

That is how I started. I used Spring to provide a datasource, test properties through the PropertyPlaceHolderConfigurer and PropertiesFactoryBean and a few other common objects I wanted to load. In my onSetUp methods, I would create common artifacts relevant to the abstract test class. I would even have tests to make sure those artifacts were initialized properly. In the class which extended the Spring class, which loaded the DataSource, I made sure the DataSource was not null. More specialized subclasses would have more specific artifacts and tests for them.

Eventually I had a hierarchy of tests to reflect the different types of functionality in my system. Since I have a message system, I soon found that tests for one message type was relevant to others, so I moved some tests into abstract base classes. It would be hard to give you guidelines beyond the Spring documentation because it depends on your appliation.

I think there might be a few talks given about integration testing and Spring. But I don't have a link to one at the moment.