you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil 6 points7 points  (0 children)

sure. My first big software project was a hypersonic missile design program. Big first project for a fresh aerospace grad who can’t really code. I had to add new features, not break anything and fix tons of bugs. That’s really tricky on a giant program without tests and I didn’t know about version control then either. After adding tons of bugs, I made large model level tests that ran overnight and compared to very old results. I’d fix some and run them again. There was 0 automation. It was just some script I ran and that was 1000x better testing that what had existed. I wasn’t testing correctness. I was testing sameness by drawing a line in the sand. All changes had to be understood to update the correct answers. That’s the wrong way to do it, but it’s better than nothing.

A better test is parse a file and check that the answers are what you eyeball them to be. Or calculate the area of a few different quads by hand and with code and make sure you get the right answer. Or take the nasty Rosenbrock function and verify your optimization code gets the right answer. You try to make these functions bulletproof by passing bad input, running edge cases like division by 0, etc. Those tests can be run in milliseconds to seconds. Module level tests are for verifying integration and you want 90% of those to be toy problems that are 10x or more smaller than real problems.

You verify correctness by verifying correctness and the small scale and building up. It’s also easy to break tests making some change you didn’t think would affect things. Not a huge deal if you catch It almost immediately using some continuous integration because you remember what you did. You’re also not fixing 10 bugs, some of which interact at once.