Re: Recommendations re tests wrt a reference implementation

First, I think guinex has a good point: consider not rewriting your codebase. Instead try refactoring your existing codebase before adding your new features. I'm guessing you're thinking about rewriting because the current codebase is becoming difficult to maintain. If you take the refactoring route, you should be able to use unit tests from the initial application to ensure that you don't regress upon refactoring or addition of new functionality.

OTOH, if you feel that the code is beyond hope and choose to go the route of a complete redesign, or if you want to make some principle changes to the design of the code, the main problem you'll run up against is that the unit testing methods that are most documented and many of us are comfortable with won't cut the mustard because your updates will break many of them. Instead, you'll need to do some sort of black box testing. Write your tests against the initial implementation, but only run them against your top level application. If it's a web app that means using WWW::Mechanize along with Test::More. If it's not, you'll need to find a different testing module; for example, Test::Output is useful for testing the results of applications that generate STDOUT and STDERR content for checking.

perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi
+n(q{},map{sprintf(qq{%010u},$_)}(2**2*307*4993,5*101*641*5261,7*59*79
+*36997,13*17*71*45131,3**2*67*89*167*181))=~/\d{2}/g));'
[download]

Comment on Re: Recommendations re tests wrt a reference implementation Download Code

Replies are listed 'Best First'.
Re^2: Recommendations re tests wrt a reference implementation by blazar (Canon) on Jun 22, 2007 at 08:27 UTC
First, I think guinex has a good point: consider not rewriting your codebase. Instead try refactoring your existing codebase before adding your new features. I'm guessing you're thinking about rewriting because the current codebase is becoming difficult to maintain. If you take the refactoring route, you should be able to use unit tests from the initial application to ensure that you don't regress upon refactoring or addition of new functionality. I understand both guinex point and your expanded explanation about it. The point is, the original app was written naively with no tests in mind or any other control structure, and it has grown more than initially expected. It has served me right since then: but it is poorly written and it lacks functionality that for some reason it would be not that easy to just cram in. Thus following the disciplined approach most of you suggest, I would modify it with small incremental steps, also gradually adding tests to make sure I don't break anything step by step: I do agree that this is the most reliable way of proceeding. But it's also more work than I may want to spend on it: the original app may have not been perfect - yet my primary concern is that the new one just behaves like it when no new functionality is adopted. As far as the actual way of rewriting goes, I'm not really sure it will be from scratch: indeed I will probably still gradually modify the existing codebase, preserving the original one apart. But to also add tests for the latter, however good in principle, would be much like duplicating the efforts. So I think I'll take a lower profile approach and leave some junk in, duly hidden under the carpet.	[reply]

Replies are listed 'Best First'.

Re^2: Recommendations re tests wrt a reference implementation
by blazar (Canon) on Jun 22, 2007 at 08:27 UTC

First, I think guinex has a good point: consider not rewriting your codebase. Instead try refactoring your existing codebase before adding your new features. I'm guessing you're thinking about rewriting because the current codebase is becoming difficult to maintain. If you take the refactoring route, you should be able to use unit tests from the initial application to ensure that you don't regress upon refactoring or addition of new functionality.

I understand both guinex point and your expanded explanation about it. The point is, the original app was written naively with no tests in mind or any other control structure, and it has grown more than initially expected. It has served me right since then: but it is poorly written and it lacks functionality that for some reason it would be not that easy to just cram in. Thus following the disciplined approach most of you suggest, I would modify it with small incremental steps, also gradually adding tests to make sure I don't break anything step by step: I do agree that this is the most reliable way of proceeding. But it's also more work than I may want to spend on it: the original app may have not been perfect - yet my primary concern is that the new one just behaves like it when no new functionality is adopted.

As far as the actual way of rewriting goes, I'm not really sure it will be from scratch: indeed I will probably still gradually modify the existing codebase, preserving the original one apart. But to also add tests for the latter, however good in principle, would be much like duplicating the efforts. So I think I'll take a lower profile approach and leave some junk in, duly hidden under the carpet.

[reply]