Member Avatar for Jusa

I've thought about getting into test-driven development myself, but one thing I don't quite understand yet is what happens if I make a design mistake, like create a class and later on realize that it should be removed altogether. Removing it would mean all the tests I've written for that class would fail, right? Should I then just remove or modify the tests, too? Somehow it sounds like it shouldn't work this way, but maybe I'm missing something :-/

  • 2 Contributors
  • 2 Replies
  • 95 Views
  • 13 Hours Discussion Span
  • Latest Post Latest Post by Jusa

Dani AI

Generated

Short answer: a test suite that breaks when you remove a class is working as intended. Tests capture observable behavior and intent, so when the design changes the tests also need to be reconciled with the new design. That does not mean tests are useless — they are the safety net and documentation that tell which behavior mattered.

A practical workflow that fits TDD:

  • If the new design replaces or moves behavior, write the tests that express the new contract first (fail), implement the change until those tests pass, then remove or adapt old tests that no longer match the desired behavior.
  • If the change is purely an internal refactor with unchanged public behavior, keep the public/behavioral tests untouched and refactor the implementation until everything stays green.
  • Keep changes small and atomic and use a feature branch so history preserves the previous tests and rationale (handy if the change was mistaken).

Commands and checks commonly used when removing a class (Python projects):

git checkout -b redesign/remove-old-class
pytest                    # run full suite frequently
grep -R "OldClass" tests/  # find tests referencing removed class
# update or move tests, then commit small changes:
git add -A && git commit -m "Replace OldClass with NewAPI: update tests"

Practical tips: prefer tests that assert behavior through the public API rather than internals, use dependency injection or mocks to reduce coupling, and archive or keep old tests in VCS instead of permanently deleting them if they encode useful intent. As noted, TDD helps reveal dependencies; as pointed out, tests do get changed—do it deliberately, with small commits and clear commit messages.

Recommended Answers

All 2 Replies

Member Avatar for Narue

>Should I then just remove or modify the tests, too?
That makes sense. You should also modify the tests that rely on that class as well, which (depending on your level of coupling) could mean changes in other classes and other tests.

Member Avatar for Jusa

Ah, well, I guess I was thinking too complexly. At least TDD would make it easier in this case to spot dependencies and fix them away.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.