Loading ...
Sorry, an error occurred while loading the content.

11453RE: [XP] Refactoring legacy code

Expand Messages
  • Robert Watkins
    Sep 3, 2000
    • 0 Attachment
      Thomas O Matelich writes:
      > The biggest downside I see is that backfitting UT's is hard
      > enough, but putting in
      > FT's? Ouch. Of course, you could use non-automated FT's until
      > you have some sort of
      > framework set up I suppose.

      I've just been put on a project where the entire group (down to and
      including the admin assistants) upped and left in a couple of weeks. My
      biggest challenge right now (aside from getting my brain (which these days
      seems only as big as a reasonable sized moon) is convincing my PHB that we
      need to get some automated tests in. The current code seems reasonably
      stable (ie, the bug reports aren't drowning us), but it's organically grown
      code over 10 years, and we just can't say for sure what we break when we
      change things.

      As a first cut, what I want to do is come up with a bullet-list of the
      functionality, then take something like WinRunner and just record each
      interaction. If nothing else, we'll know that the program isn't GPFing. As
      we make changes, we'll extend the tests, and hopefully start putting in some
      code-level tests.

      (My personal saving grace here is that I'm in seagull mode... they're hiring
      new people, and once I get them trained up, I'm going back to my old
      project. Hopefully, I can test-infect the new guys quickly enough.)

    • Show all 28 messages in this topic