Tag Archives: TDD

Learning Tests are Free!

Posted on by
3

My son is studying computer science at U of I in Chicago. He is taking an operating systems class and has to do some projects in C. (Some things change, some things stay the same.) He had an internship over the last 8-9 months and was doing TDD in Java. So he might be in the early stages of a test infection.

He has not done much C so he’s got some learning to do. I thought I better show him CppUTest. He could use it for a play ground to learn some of the subtleties of C, as well as use TDD.
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 →

Physics of Test Driven Development

Posted on by
23

Test Driven Development is a challenging practice. Why should you bother to learn it? You should learn it because it is a productive and predictable way to develop software.

Let’s compare TDD to the most popular way of programming, something I call Debug Later Programming. In DLP, code is considered “done” after it is designed and written. After the code is “done” it is debugged. Hmmm. Interesting definition of done isn’t it? The definition fails to include about half the effort.

Continue reading →

Tests vs. Short Term Cache Between Your Ears

Posted on by
Reply

You have someone else’s code. You have to use it. To use it you have to learn it. If the code had automated unit tests you could read the unit tests to see how the code behaves. But, it probably does not have unit tests. So, you read the documentation. The documentation usually leaves some room for interpretation in the best case. It lies and misleads in the worst case. What do you do? You read the code.
Continue reading →

Now I’ll really use test driven development to write device driver code

Posted on by
7

In the last article, I added tests to existing code. So I did not really do Test Driven Development. I did Test After Development. Let’s do some TDD now and design the block erase function. I’ll go from the spec, to the test to the code.
Continue reading →

Who says you can’t test drive a device driver?

Posted on by
3

I keep hearing that you can’t write unit tests for device drivers. I don’t believe that’s true. To disprove this claim, I thought I would find a device driver and write some unit tests for it. This blog posting shows what device driver unit tests look line.

Continue reading →