In VLSI design, especially when designing ASICs or ASIPs (not so much on FPGAs), people make a real fuss about testing. For a good reason, since A) the fabrication setup is expensive and really slow (you speak in terms of months), and even more important, since B) the fabrication is error-prone. As a side note, in practice it is not economic to fabricate error-free, as such a process would be clearly far from the density limit. Hence you usually accept a yield of, say, Y=95%. Having a fault coverage T leads to a defect level of DF = 1-Y^(1-T). To minimize this you want a high fault coverage (e.g. T > 99.9%).
Part A) is about functional tests to ensure the IC does what you intend, while B) is about testing whether the chip fabric actually produced error-free what you told them to - you examine every single IC with this test, often directly on the waver.
Interestingly there is a very nice tool support for B). A common practice are scan chains, a simple technique where you insert additional logic to systematically set the values of every single register on the chip with only few additional I/O pads (actually, a tool inserts this automatically). Using such chains and a given fault model, another tool then automatically generates a huge set of test vectors, trying to reach 100% fault coverage with as few vectors as possible.
Now the odd part, when we come to A): No one seems to apply Unit Testing, or has ever heard of anything like "agile" methodologies. Ok, they do functional testing, but only the on whole chip (and to be fair, also on IP blocks - usually this means generating an input vector sequence and compare the simulated outputs with the expectations); and it probably depends on the environment. But I think there doesn't even exist a tool like NUnit/JUnit for VHDL, let alone a continuous integration server (although you could theoretically write some NAnt task adapters and use a common CI server). Looks like there's not that much communication between the hardware and the software world, or at least not on methodological aspects?
Btw, there is a ruby based hardware description language called RHDL, trying to unify object oriented and agile concepts with VHDL. Might be interesting!
To be precise, I've neever seen a easy-to-use software-tool for electronic engineers. The software in this area seems to ignore all the UserInterface Guidelines and Best-Development-Practices.
That's a really bad sign, also because Unit-Testing was invented by the hardware-engineer community. and not by the software-developer community.
I sometimes think the bad software quality in this area is because hardware-engineers are developing them.