Test Before or Test After, that is the Question

In Jeff Langr’s blog, Jeff responded to an assertion (from someone Jeff calls Schmoo) that writing tests after developing a unit of production code takes less time than using TDD to create production code and its tests. For starters, I am happy the discussion is about when to write the unit tests and not if.

I think a model would help us talk about this issue. It would be great to have some real numbers in the model; that will be hard. But for starters let’s look at a model. Maybe then someone can figure out how to put some numbers to the model.
Continue reading

Agile Design and Embedded

One important realization on the journey from a BDUF approach to an iterative and agile approach is that design is never done. Designs evolve. The waterfall emphasis has been to unnaturally try to control software physics by imposing requirements freezes and burdensome change control. The process of developing software is part science and part creative. You are applying science toward the invention of something. Design is capturing knowledge both about what the end user need is, and one solution to that need.
Continue reading

What Should you Expect from a Unit Test Harness

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

Don’t Let Embedded Tool Chain Slow You Down.

During my TDD session at the Embedded Systems Conference yesterday, I did a demo. Before the demo, I make the case for TDD as a way to prevent bugs (see Physics of TDD). For the live demo I usually code on my mac and run the tests there as well. The question always comes up: “You are running tests on your PC, can you run them on the target?” or maybe “Sure you can TDD on a PC, but what about the real hardware?”
Continue reading

Deep Agile Embedded Brain Storm

Let’s say you were an embedded systems developer, and you were planning on attending a conference like the Deep Agile Embedded.

What questions would you hope you could get answers for at the conference?

What if you already knew it all but were sending your boss, co-worker, or CEO who needed to learn more, what would you want them to hear about?

Would you want to do some hands on Test Driven Development?

Here are some of the questions we have so far:
Continue reading

No time for proactive tests

Every now and then I get a new automatic update. I usually just press install. Today I browsed the release notes for the Adium IM client update (below). There are six new features, denoted with a “*”. The rest (about 30 of them) are fixes, meaning something was broken. These guys must be too busy to proactively test Adium. Test Driven Development probably would not work for them 🙂
Continue reading

TDD Stepping Stones

Imagine you are trying to cross a mountain stream. You could make a running leap and get to the other side. Sometimes that works, other times you get wet. When there are rocks sticking out of the rushing water, you can step from rock to rock and get across the stream without getting wet. Sure there are some streams you can jump across, go ahead and jump. Other streams require a more careful approach.
Continue reading

Learning Tests are Free!

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