Tag Archives: test-driven-development-tdd

What Should you Expect from a Unit Test Harness

Posted on by
Reply

A unit test harness’ job is to provide:

  • A concise common language to express test cases
  • A concise common language to express expected results
  • A place to collect all the unit test cases for the project, system, or subsystem
  • The facilities to run the test cases, either in full or partial batches
  • A concise report of the test suite success or failure
  • A detailed report of any test failures

TDD and the Big Framework Part II

Posted on by
Reply

In TDD next to the Big Framework we looked at a design that helps to isolate your code from the BigFramework. That article only showed half the story. Lot’s of times the big framework has the attitude “don’t call us, we’ll call you” built right in. Your code has to register somehow with the framework, then when you ask it to do things, it calls you back, asynchronously, with the result.
Continue reading →

TDD next to the Big Framework

Posted on by
Reply

TDD next to the Big Framework

We’re trying to create a new executable process that plugs into a pretty big services framework for a telecom system. Our code and framework are in C++. We’re test driving our design. Within a few tests, we were confronted with having to inherit from a framework class. No big deal, or so we thought. Soon the dependency chains became evident. Kind of like this picture, but worse. Continue reading →

Bug Fixes and TDD

Posted on by
Reply

Code has bugs. Finding a bug’s hiding place is a challenge. And, you know that killing a bug often breaks code in unexpected ways, hatching more bugs to discover, hunt down, and kill.

If you created your whole code base using TDD, you could prevent many of these new bugs. But you have legacy code; code without tests. How should the professional software Orkinman apply DDT, I mean TDD, to bugs in existing code. (Orkin (r), do i have to do this in a blog?)
Continue reading →