Three Steps to less duplication

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.
Continue reading

I miss constructors

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.
Continue reading

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

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?

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