Actions
Forum Thread Details
  • Replies 15 replies
  • Subscribers 468 subscribers
  • Views 1386 views
  • Users 0 members are here
Related

TDD and Embedded Programming

mconners

A while ago, during the "Help a STEM Educator Out" thread, the topic of TDD was discussed briefly. I noted that I was a proponent, but I felt the challenges to developing the tools and frameworks for embedded development would be daunting.

 

I was not aware at the time, but someone has addressed this.

 

https://www.renaissancesoftware.net/blog/

 

This is the blog of James Grenning, who had written a book on the topic in 2011.

 

The Pragmatic Bookshelf | Test Driven Development for Embedded C

 

There exist on the web links to free versions of an ebook, but I'm not sure whether they are legitimate copies, so I won't link them here.

 

I have skimmed the book and it appears to be very well written. With a forward by Bob Martin, who is one of the chief proponents of TDD and agile.

 

I was fortunate enough to have been taught TDD by "Uncle Bob", as he is called, and another person mentioned in the book, Michael Feathers.

 

So to me, his endorsement carried a lot of weight.

 

One of the things I like about the book is that it emphasizes software development as a craft, and developers as craftsman.

 

I plan to investigate adding these methods to my embedded development.

 

Mike

Parents

  • Do you mean this thread?  We're looking for Top Members who want to help STEM educators!

     

    I haven't officially used TDD yet, although with a brief review of the wikipedia page, it appears that I somewhat follow the idea.  I always define the baby steps needed to accomplish a big task, and write code to accomplish each of those steps.  Some of the old time coders around here don't like the way I do things, as there is a very short cycle involved.  I'm constantly starting and stopping things, making sure one thing at a time works before moving to the next.  Essentially, my view is that I'm changing the minimum number of variables.  I think this is especially important when working in an interpreted language such as Python, as it's far too easy to add a bunch of control structures that don't get tested until you've deployed the thing and someone does something you don't expect and didn't test for, resulting in a runtime error.  Doesn't look good...

     

    I find the Grenning blog entry #458 "Engineers and Programmers, Stop Writing So Much Firmware" fascinating.  It's always a balancing act.  As we say here at the day job, we might not have time to do it right the first time before delivery, but we always have the time to redo it.  This is driven by the customer who wants things and wants them now.  I know some people are able to get on the Agile high horse, and stick to their principles, but I don't think that's applicable to most of the real world, where lowest bidder wins.  Also, depending upon the market/client/customer, one might not wish to produce something open and easily maintainable.  Occasionally, we get paid to build something that is explicitly open and maintainable, but naive idealism aside, the reality is that it's easier to make something that ensures job security.  Just sayin'...  LOL

     

    A thought though, used properly, couldn't firmware really be the place to write the code that would keep compatibility between hardware and software?

     

    @DAB, one of the thoughts that I keep running into is that design takes about half of a projects resources, and testing/debug takes about a third, leaving a really small window for the actual coding.  I think Agile-related ideas are good at getting the mingle started early in the process.  Seems the same with TDD, right?

  • in reply to AnalogNotes

    Yes, Doug, that was the thread I was referring to. image

     

    Mike

Reply Children
No Data