Continuous code re-factoring – why we need to do it – part-1

tdd-red-green-refactor-diagramContinuous Code re-factoring is an important part of software development. The growing number of adoption of Agile development, code often written to move fast. The problem with this approach is the code may lose the usability since it often looks to solve the problem then deliver re-usability.  Agility of business problem often changes abruptly. The problem you solved a year back may not be relevant now or need more better solution. This will increase the “Technical Debt” in the code and eventually eat up your entire budget.

The benefits:

I’ve listed some of the key benefit of doing continues code re-factor.

  •  You will know which part of the code has more technical debt. There by fixing it continuously improve the code quality and stable the product.
  •  You can be very sure that there is no redundant code in your product. You make sure you are following DRY principles.

Remember “The code you’ve not written is the code you don’t need to debug”

  • Code re-factor along with the team improves the domain understanding for the team. It will help the product on innovation and continues improvement of the quality.
  •  Continues code re-factor also help you understand your code better. This will enable to estimate cost and time effort of future business requirements. This will enable no surprise in product delivery.

Reason people not to do Continues code re-factoring:

1. Often people excused not to do code re-factor is that the code already running fine. Re-factor may introduce bugs and the cost and effort to test it out is very high. But if you can see adding more technical debt eventually increase the maintenance cost of the product. I believe every product spend almost 80% investment in the maintenance rather than the development.

How I can do it?? – The challenge and the solution: 

The question will eventually raise, okay I want to follow continues re-factor code principal at the same time I want to reduce the risk of the product getting break. I don’t want to burn my testers every time I’m doing the code re-factor.

The best way is, as you guess “Automation Testing”. Code Coverage is an important principle in software development. It make sure each and every piece of code been covered with your unit test cases so that you want face any surprises during testing phase.

Well, my experience is all about software development using java technologies. One of the recent trends is the Dependency Injection. CDI (Context Dependency Injection) was included as part of JEE6 and it is growing strongly. So the container takes responsibility of injecting the object when it needed rather than we creating it. Well it is reducing the burden of development, but increases the pain of unit testing. The standard JUnit test framework all run on a standalone and have no connection with java containers. So we need to mock all the objects getting injected by the container. Mocking leads to error. I mean you can’t really test the real object. There comes Arquillian testing framework to help you around. Arquillian is built around JUnit framework and ability to run inside the container. So instead of build and deploy the entire infrastructure, you can deploy the class or object you want to test in to the server and test it out. There by you can automate most of your code base.

But will that enough. No. Often web based application consists of well-defined web flow. we need to navigate through certain flow to achieve certain functionality. It is more of an integration testing. How to automate it? How we can automate a test case like end user using the product. how we can capture the journey. Selenium is answer for you. Again it is built on top of JUnit framework, which can invoke a browser on its own and execute the flow. It has wonderful plugins for all the leading browsers. Selenium browser plugins used to record the flow / URL you are accessing on your browser and export in to auto generated JUnit test cases. Beauty isn’t it???

In part 2 I have covered how to get start with Arquillian. In part 3 I have covered how we can automate browser testing for an end to end application using Selenium.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s