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:
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:
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 :).
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!