In my team, we are about to start the reimplement of a service. One of the important steps to do to accomplish this is how do we ensure that we are doing it in the right way and we are not introducing new bugs.

So, what we have in mind is create a bunch of test to verify the following:

  • The behavior. Both services should behave the same way (store data in the same places, send same, notificacions, etc...)
  • Results. Object returned by the service's calls should be exactly the same.

So, the things that we have thought is to do the following:

  • Create a set of test that verifies the behavior and results of old service.
  • Create the new service adding unit test, and whitebox integration test for the new service
  • Create some kind of "Mirror test" that checks if the new service is working as the old one. Is there a way to do this?

Thanks for any help.

Note: None of the code of the previous version is reusable. There is no test for the older version of the service

[Edited]replaced original word "migrate" with "reimplement"

  • So, you are not migrating a web service, you are rewriting it right ?
    – jsedano
    Jul 12, 2013 at 22:32
  • I think the right answer is both. The older service is in .Net and we are moving to Java.
    – Orposuser
    Jul 14, 2013 at 19:14

5 Answers 5


you can write approvaltests that are available for .net and java.

the idea you implement a test-client that calls the old service with typical inputvalues and record the corresponding output from the service.

then you execute the test-client against the new service: The approval-test-tool complains if the output is different from the previosly recorded output.


Well, after diving deep in this, we have two possible solutions:

  • Replay prod data: It will be kinda complicated to do it, but the good thing is that if you can capture and replay prod data against your service, then all whitebox integration test will be done for you. the bad thing is that you are just testing the inputs and outputs and not how the data is changed by the service.
  • A different approach is the following: Apply factory pattern for both service's clients, the old one and the new one, then create a test for the old service (here you want to check result objects and data changes), migrate the service, test your new service against the test of the old one.

If there's no test for the old service, and I assume you don't want to spend time creating one... then you have to create one, but one that will still work with the new service.

I'd recommend selenium and/or cucumber (or equivalent) as you're reimplementing it, these drive the overall website from an external PoV and record the results you get back. This kind of integration test is much less complicated than adding unit tests to existing code, and will provide you with a set of requirements for the new service. Once you've get some tests for the website, you can repeat it, then you can replace it and see if it still works.

  • If by "web service" the OP means an API, then Selenium is probably overkill here. I'm a huge fan of cucumber-style acceptance tests, but this question seems to be more about working with legacy code than it is about improving product quality, and acceptance tests are worse than useless if they're written by a person or team who has no intention of spending any effort maintaining them or even running them on a regular basis.
    – Aaronaught
    Sep 17, 2013 at 0:41

I've worked on a re-implementation of a large IT project that faced this exact challenge.

There are several issues that you are likely to face.

  • The original implementation will have existing client apps which may be reluctant to change their client programs and retest to accommodate any changes.
  • The original implementation specifications may not reflect the original implementation. What is the goal for the replacement?
  • The original implementation is likely to have bugs. Client apps are likely to have been programmed to accept the bugs as 'features' Fix the bugs and break the client apps.

If the goal is a direct, drop in replacement, then you really do need to create replay tests that take test messages and their response from version 1, and create integration tests that pass these messages into version 2 and run diff on the output.

Some differences will be acceptable. Time stamps, version numbers, some ID's etc... but you will identify many bugs this way long before your client apps get near the rewritten system. Some automated tools may help if your service is simple enough, but my guess is that you will end up scripting your own test suite.


What you have described is basically exactly what Unit Testing can provide for you when doing large refactoring or in your case, an entire rewrite.

You'll want to pay particular attention to making sure your interface does not change at all as you will have existing clients, and having a full on integration test might be worth looking at as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.