Porting 4.5K lines of C to Go
> As far as I can tell you can’t step through tests in the debugger<p>Rant time. What to do when you write a test framework.<p>1. When test fails, print everything possible: desired expression, desired value, actual exression, actual value, line and file of failing call. When printing line and file, make the format configurable, with the default being the prevailing standard for the system, so that people can get clickable links in their text editor or terminal with a minimum of hassle.<p>About 90% of the time, this will give people everything they need in order to at least get started on fixing the failed test<p>2. Don't make it hard to use the debugger. The remaining 10% of the time, people will need to step through the code. Some measurable fraction of the other 90%, they'll also end up needing to do this, because it looked like it was something simple but actually it was more than that. So don't make this hard<p>3. See steps 1 and 2<p>This might sound obvious, but it clearly isn't, because I've used several test frameworks that make running in the debugger rocket science, and print literally nothing but your own message (if even that) when the test fails. Like, you do 'assert.equals(x,y)', and it doesn't even show you what the values of x and y are, let alone figure out that maybe "x!=y" would be an obvious thing to print.<p>This may not sound like a big deal with my stupid little example, but after you've written several tens of these you will start to see my point.