The Most Descriptive UVM Tests Ever Written

If you want to know how the uvm_printer works, in detail, I don’t think you’ll find a better explanation anywhere than my unit tests. This comes after I went through a refactoring exercise in our open-source UVM-UTest project – that’s where we’re unit testing the code in the UVM framework – specifically for the purposes of making my code more readable.

Here’s one of the tests I’ve written to get the idea of where I’m going:

Screen Shot 2013-05-28 at 4.02.11 PM

The reason I’m happy with this is that as you can see in that snapshot, I think I’ve made my code human-friendly. When we got started with the UVM unit testing, I thought a descriptive test name would suffice. But after finding myself getting a little lazy, I accidentally took “descriptive” to the next level and ended up with the approach I’m showing here. In a nutshell, I have tests that:

  • focus on what is relevant;
  • exclude what is not relevant; and
  • are very english’y.

For those reasons, I think I’ve given people a chance at understanding what’s supposed to be happening.

Here’s a few more examples from that same file, all of which focus on the behaviour of the ‘print_int’ method:

Screen Shot 2013-05-28 at 4.02.42 PM

In case it’s not obvious, I’ll point out that I’m using a pattern of Given-When-Then to differentiate between setting up the UUT (Given), exercising it (When) and then confirming the result (Then). That pattern is something I’ve borrowed from a technique called behaviour-driven development (BDD) which I’ve written about before on AgileSoC.com. BDD is an agile technique where a product is described as a list of behaviours. This as opposed to a bullet list of features or suite of acceptance tests, both of which hardware developers would be more familiar with. I find the Given-When-Then structure does improve the readability significantly so it’s something I’m going to continue experimenting with. With proper tooling, behaviours become an executable specification (see Cucumber for more on that). For this project, let’s consider what we have a poor man’s executable spec!

By the time we’re done with our UVM unit testing experiment, we should have several examples of how we’ve followed this approach; in the uvm_printer and elsewhere in the library.

Now… are these the most descriptive UVM tests ever written (like I suggest in the title)? I guess I don’t really know… but they’re certainly the most descriptive tests I’ve ever written which is why I figured them worth talking about here :).

-neil

PS: if you want to know more about UVM-UTest, you can take a look at my last post: We’re Unit Testing UVM

PPS: Pretty much everything I know about BDD came from a talk be Liz Keogh at Agile2012 in Dallas. Her talk called BDD: Look, no frameworks was quite good. Hopefully I haven’t mangled the message to badly!

Share/Bookmark

About nosnhojn

I've been working in ASIC and FPGA development for more than 13 years at various IP and product development companies and now as a consultant with XtremeEDA Corp. In 2008 I took an interest in agile software development. I've found a massive amount of material out there related to agile development, all of it is interesting and most of it is applicable to hardware development in one form or another. So I'm here to find what agile concepts will work for hardware development and to help other developers use them successfully. I've been fortunate to have the chance to speak about agile hardware development at various conferences like Agile2011, Agile2012, Intel Lean/Agile Conference 2013 and SNUG. I also do lunch-n-learn talks for small groups and enjoy talking to anyone with an agile hardware story to tell! You can find me at neil.johnson@agilesoc.com.
This entry was posted in Functional Verification and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>