I still remember those good old days when the database configuration used to begin in the project with three holy scripts create.sql, data.sql and drop.sql. Every time you make a change to object model (which you do during early phase of projects), the data model needs to be adapted. As soon as the project grows, the mess begins. Additional update scripts are added for every release and someone needs to maintain those changes also in the three holy scripts. This is quite a cumbersome and error prone job. On top of that if you need ability to rollback a release, then complexity of the scripts only increases.
Continue reading “Database Change Management with Liquibase”
Writing clean, isolated and efficient unit test is often a challenge for developers. Efficient test should cover all the possible business scenarios. To create test for covering multiple test scenarios, you need more test data.
For instance, imagine you are writing a test for some Service component. Now if the responsibility of this service is to just collect some data from DAO Layer and pass it on to Business Delegate, life is easy. You can create a mock for DAO using frameworks like EasyMock and you are done. But that’s not often the case. For testing services with complex business logic, its not sufficient to return dummy data. In this case, we create the expected test data and mock the DAO to return the expected data. If this input seed is a simple object, its few additional lines of code and we are done. But what if the test is dealing with complex data model? Normal practice that I observed amongst developers is some private methods are created deep down the test to generate test data – generateXXX().
Situation becomes more worse when after few months there are some changes in the domain model. The developer opens the test and the thought to fix the clumsy code can really make him fussy. If he is not religious about unit testing, he might try to fix the test data instead of test and the whole motivation is at stake. Don’t worry. XStream @ Rescue.
XStream is a simple library to serialize objects to XML and back again. It supports de-serialization to nested object structure.
Input XML:
<person>
<firstname>Joe</firstname>
<lastname>Walnes</lastname>
<phone>
<code>123</code>
<number>1234-456</number>
</phone>
<fax>
<code>123</code>
<number>9999-999</number>
</fax>
</person>
Conversion Code:
XStream xstream = new XStream();
xstream.alias("person", Person.class);
xstream.alias("phone", PhoneNumber.class);
Person newJoe = (Person)xstream.fromXML(xml);
As you can see, creation of nested objects is extremely easy with XStream. We just need to create aliases for Custom classes to XML elements. That’s the only configuration required to work with XStream. XStream is lightweight, simple and does not support validations. If you need XML to Object conversion with validations and complex business rules, Commons Digester could be the choice.
With this approach you can create a XML for the test scenario and de-serialize in the test. The test would definitely take a bit longer to execute but is more clean, readable and maintainable.
Have you ever spent days rewriting the whole application burning the midnight oil? Well, I don’t think you are the only one. In early days of my career I also made similar mistakes or was a victim of mistakes made by fellow developers. Having taken this roller coaster ride, spending sleepless nights fixing the code, I learned a new mantra – Tune Early Tune Often. In most of the enterprise development cycles, performance testing and tuning is done pretty late. Typically we start worrying about it during system testing and by the time (if at all) application goes into UAT phase, performance becomes the critical requirement. So if we are building applications where performance is as important as any other functional requirements, why not invest some time addressing it in early development phase?
Are you ever involved in project estimations? Did you ever enjoy this task? I sure know the answer is big NO. This is because at the planning phase of the project there are lot of unknowns. Some members of the team are given the sheet to bring out those magic numbers. Its tough to get the realistic figure this way.
Planning Poker is the answer to some of the problems. Planning Poker is a team estimation meeting. So all members of the team i.e. developers, testers, project manager are present for the meeting. Each member is given a deck of 13 cards. You can see the cards have Fibonacci sequence on it. Whenever a story is to be estimated, each member selects a card from his/her deck that represents the weight of the story and places it face-down on the table. The weight is the unit of amount of work to be done for the story. When all team members are done, the cards on the table are revealed simultaneously. So this technique makes sure that the estimates are not leaned on team’ estimates (really?).
It is very likely at this point that the estimates will differ significantly. If estimates differ, the high and low estimators explain their estimates. This is a good practice as you get to know different views of the team members on a story, and catch some point you might have missed.
I’m using this story point estimation technique in my current project. We have a small team of 5, its working quite well. But I personally feel that there should be different meeting set for developers to come up with CUT i.e. Construcion and Unit Testing efforts and one for testers to get the System Testing, Integration Testing and Acceptance Testing efforts.
So get ready to play poker at work :-) !!
In one of my projects I did some work on process improvements. The main target was to set up independent developer workstation. We stubbed out all the interfaces. Earlier we tried to share a development database in a group of 4-5 developers. But believe me, I’ve seen developers throwing coffee cups when someone touches their data. Imagine you spending couple of precious hours out of your day on analysing the data and then getting it in right state to run your test cases and the moment before you hit “Run”, someone drops in and mess up all your data. How insane!!
Well the answer is simple, give me my own database and save yourself from the typical excuses. I evaluated couple of open source databases like MySQL, Postgres, EnterpriseDB and finally settled on OracleXE. Well we use Oracle in production and hence its easy to setup development environment with OracleXE with almost no extra tweaks in the scripts. I used DBUnit for testing database modules. It works quite well, but I think my strategy to setup test data was not optimum. It takes bit longer to run the tests now. I used Dumbster as a fake SMTP server and XStream for creating enriched objects for my tests.
Also one useful tool I would like to share here is DBMonster. It really helped me for generating mass random test data. Now I don’t have to request the DBA’ to give me test data. Well its not that simple also, as you need to understand the states of the dataset to create the seed xml files. But I think its still better than having human dependencies.
Happy Development :-) !!
Aparna Chaudhary Blog 