Best way to test a reimplemented web service

Question

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"

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.