[bt-devel] refactoring::namespace

[Greg Hellings]

On Thu, Jul 8, 2010 at 5:29 AM, Jaak Ristioja <Ristioja at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08.07.2010 12:18, Martin Gruner wrote:
>> So I guess you don't like the concept of "test driven development"?
>
> No, I do like it. Unfortunately, I don't think we can properly do it right now - it
> wouldn't be reasonable, rather a waste of resources. Mainly due to the refactoring which
> will continue for a long time, things will cardinally change, even architecturally. Test
> driven development would have worked best if we would have done it from the start of the
> project. Unfortunately, this is not the case at the moment.
>
> Personally I'd rather concentrate our efforts on refactoring. I think that only after
>  1) a tremendous refactoring effort and
>  2) writing tests for all code (which we have after refactoring)
> are we reasonably able to continue with test-driven development, if so desired. In short:
> refactoring first, tests next, then test-driven development.

The one major problem with this plan is that BibleTime code, while not
necessarily well-written, is very mature.  Over many years (I know
I've been a user since 2002 at least) it has been altered and patched
to handle lots of obscure cases and bugs and so on which may not be
obvious to any of us.  Some of them may even look like bugs or
non-optimal portions in the BibleTime code to serve as work-arounds
for quirks in libraries BibleTime uses.

Without a whole slate of automated tests, some of those work arounds
could be factored or optimized out of the code-base and we'll have to
wait for another bug report to come down the pike and then someone
will have to figure out how to get a workaround for that issue, all
over again.

In addition to the QTest class from our Trolltech benefactors there is
also a whole CTest suite in CMake which operates similarly to how Troy
has setup the SWORD tests.  We really ought to leverage both of these
utilities and write the tests before any more refactoring or
optimization is done.  If that is not going to happen, then we should
just discard the bad parts of the codebase and rewrite the application
from scratch, because we will not be leveraging the old code anyway.

--Greg