Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have a web application which contains a web service with over 50 methods.

The application is currently installed at a number of sites and is currently being maintained by one developer.

The application is currently a single user system where all the data is stored in XML files.

One of our main tasks is to make it a multi user system whilst at the same time put in a database (RDBMS or NoSQL, not decided yet).

In addition to other new features we want to get a team of developers (around 5) working on other new features.

From what I have seen, the application is not testable. There are no test units and all the code is pretty much in the web service methods.

I need to put a framework in place so that the other developers can simply start working on their features using TDD and then finally when we have the database in place we can switch that in at a later date.

I was thinking of first moving all the code into libraries and then introducing UNITY and test/mocking frameworks to provide some of the services that the other developers will need. That way via inversion of control they at least have interfaces they can work with.

I am not sure if this is the right way to go or whether I should focus on some other area.

I was thinking about putting unit tests around the original code but then all the code will change later so this may be pointless in the long run.

We have a period of about 6 weeks before we get the other developers involved.

Any help would be appreciated.

share|improve this question
5  
Working effectively with legacy code. –  Oded Dec 8 '11 at 13:47
add comment

2 Answers

up vote 2 down vote accepted

IMHO you're on the rigth way... (You're thinking about pros/cons)

So I'd suggest to

  • set up CI (jenkins?)
  • write tests for code that is subject to change right before it'll change
  • devide existing code into modules (if, and only if, you can test, that this operation is a succeess)
  • introduce new APIs where needed and wrap old APIs in the first step (remove them in the second)

Hmm. Should be enough as a raw plot.

share|improve this answer
    
Thank you for your information. I was a bit panicky at the start as this a very big project but from what you have described, I feel like I am going the right way. –  JD01 Dec 9 '11 at 8:44
    
you're welcome. feel free to ask again ;) –  tuergeist Dec 9 '11 at 20:41
add comment

I would consider setting up some acceptance level test up front, rather than unit tests. It's probably not practical cover all bases with acceptance tests up front, but you can probably cover the main use cases and some smoke testing for the secondary use cases within the six weeks. Theses acceptance tests should be setup to run in CI. You also want to do a few integration and unit tests to get an infrastructure for that up and running. These should also be included in CI. Lastly give the new devs arrive give the Michael Feathers: Working Effectively with Legacy Code and ask them to read as a homework assignment. Seriously. It's brilliant book on tackling this sort of thing in a sound and incremental fashion. The very basic gist of the books approach is what tuergeist outlines in his answer.

share|improve this answer
    
Thanks for the link and I really appreciate your advice on setting up acceptance level tests. –  JD01 Dec 9 '11 at 8:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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