Aparna Chaudhary' Blog

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().

Read more…

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?

Read more…