3 ms·
I've have little experience in performance critical code. However (in non performance critical code), many of the assertions I have written are not simple equal
by gizmo686 14y ago
I've have little experience in performance critical code. However (in non performance critical code), many of the assertions I have written are not simple equality tests, but rather depend on the outcome of one or two method calls, which may require a non trivial amount of CPU.
- glimcat 14y agoMany instances of this type are properly unit tests, e.g. assert brute_method(foo) == optimized_method(foo) for foo in cases.
- jacktoole1 14y agoSure, but isn't it awesome if, instead of being just one unit tests, you can have some critical checks running in every unit test (and when running the code as a whole)? However, if you're going this route, it might be worth having a second assert macro that can allow you more fine-grained control of enabling/disabling fast asserts vs slow asserts.
- colomon 14y agoIf the number of cases is small and can be completely enumerated, sure. But there are plenty of algorithms out there where the number of cases is effectively infinite -- the matrix inversion function someone else mentioned is a great example -- where it is prudent to routinely check results to make sure the algorithm is working. (Mind you, also having a unit test to sure it works on a small set of carefully chosen cases is a great idea.)