Blog do projektu Open Source JavaHotel

niedziela, 11 października 2009

Migration to Google App Engine and unit testing.

Summary

This post describes how to migrate existing test cases (JUnit4) to Google App Engine keeping backward compatibility. It extends solution described under link http://code.google.com/intl/pl/appengine/docs/java/howto/unittesting.html. The method described here is about testing in the local environment, it cannot be applied to the production environment.

Introduction

Like the main application it is unlikely to achieve 100% source compatibility while migrating test cases to Google App Engine.  But it does not mean that rewriting the whole test suite is necessary, quite the opposite. With minimal effort it is possible to set up environment where existing test cases can be executed and, what also very important, starting from that point the common test suite can be developed further without bothering about migrating and portability problems.

It is very good programming technique to have server side code separated from the client side and being tested independently. After porting application to Google App Engine further development should cover both frameworks, so keeping common and concise suite of tests plays very important role.

Google App Engine JPA/JDO implementation requires setting up additional environment - how to accomplish it is descibed under link http://code.google.com/intl/pl/appengine/docs/java/howto/unittesting.html. The disadvantage of this solution is that it is specific for Google App Engine, so a naive approach will break backward compatiblity. Additional code should be injected for Google App Engine and not Google App Engine testing but applying an injection framework (like Guice) for very simple and only one task is like using a steam hammer to crack a nut.

Solution description

Details:

http://code.google.com/p/javahotel/wiki/GooglaAppEngineUnitTesting


Addtional remarks.

  • In this example the amount of framework specific code is greater than framework independent code. But the amount of framework specific code is the same regardless of the application size. In real application the common code (data access service and test cases) is  huge and advantages of this approach is more visible.

Brak komentarzy:

Prześlij komentarz