Posts Tagged ‘Test Driven Development’

TDD as a Design Rot Prevention System

Friday, January 30th, 2009

Coupling and cohesion have been discussed for a long time as the right criteria for judging a design. But there seemed to be no objective way to determine if code exhibited those qualities. Could TDD lead to higher cohesion and loose coupling?
(more…)

Bug Fixes and TDD

Tuesday, June 24th, 2008

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?)
(more…)

Physics of Test Driven Development

Saturday, June 7th, 2008

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.

(more…)

Tests vs. Short Term Cache Between Your Ears

Monday, May 5th, 2008

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.
(more…)

Three Steps to less duplication

Wednesday, March 26th, 2008

Like I said in my previous blog, doing all this embedded C makes me miss constructors. I’ve got a three step plan to make the lack of constructors less painful. In the previous article, we discussed the problem of duplicate setup data, and all the duplicate effort to go along with it. In this article I’ll tell you what we’re doing about it.
(more…)

I miss constructors

Thursday, March 13th, 2008

I’m working with a few teams evolving a large complex legacy embedded C application. (Whoa! That is a lot of modifiers on application.) We are trying to get unit tests in place. I think there is some 20 year old code here. And this application is not going away anytime soon. So adding tests is critical to keeping the application running and making it more maintainable for the years to come. The biggest challenge (so far) is getting the setup and initialization code together to allow a unit test to run. The first test is a bear. Once we get one going its much easier to get others going in the same area.
(more…)

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

Thursday, March 6th, 2008

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.
(more…)

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

Sunday, February 17th, 2008

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.

(more…)