Welcome back for TDD month round 2! In our first post, Test Your Own Code!, we laid out some of the motivation for using TDD with some general discussion of the mechanics and benefits. If you read Test Your Own Code!, hopefully you’ve put some thought into where it actually fits into hardware process because that’s the topic we’re tackling today. I don’t think it’s trivial, but we can definitely squeeze TDD in. Here are my thoughts. Continue reading
TDD
Test Your Own Code! (I’ve Got Better Things To Do)
November is TDD month on AgileSoC.com. This is the first of a few installments where we look at the potential of Test Driven Development (TDD) in hardware development.
If you’re unfamiliar with TDD, the first and most obvious thing you’ll notice is that TDD breaks a boundary that many hardware teams – ASIC teams in particular – consider absolutely unbreakable.
With TDD, the person that writes the code, tests the code.
[Gasp]
Before you rattle off all the reasons why it doesn’t make sense for people to test their own code, let me give you some background and attempt to explain where we’re going, both in this post and with our wild scheme to introduce TDD to hardware engineers!
November is TDD Month On AgileSoC.com
It’s the biggest thing we’ve done on AgileSoc.com to date. We’ve been planning it for a while. Finally it’s going to happen (in about a month from now)!
November is TDD month on AgileSoC.com
Starting November 1st, we’ll be taking a closer look at how test-driven development fits into hardware development. We’ll have an overview of TDD, give our opinions with respect to how it fits in to the development/verification paradigm most of us follow now and hopefully have a few examples and expert opinions. It’s 1 full month dedicated to TDD!
All this and more rolls out through the month of November so be sure to join the discussion!
-neil