TDD style unit-testing precisely guides software development in such a direction that smaller units can be independently tested
Sure, in theory. Not that it's possible to retrofit that to an existing large project in any reasonable time, but if you're starting from a clean baseline.
Extracting every single-use conditional clause into its own function so that it can be independently unit-tested, then writing a set of unit tests for each of those conditionals, then duplicating enough of the purpose of those unit tests on the original function to make sure you didn't do something like get the if{} and else{} blocks the wrong way round, or call the inSuppressionCross() function with the parameters in the wrong order ... is a huge amount of overhead. And sure, it guarantees that changes won't break the code, but unless you're in the safety-critical business where it's fine to take ten times as long to develop in the first place, it does that by guaranteeing the code never gets to the 1.0 stage in the first place.
Spending that much effort to prevent a bug which players hardly noticed for years, has minimal user-facing impact, and takes statistical analysis of the results of
thousands of players' exploration trips to discover the specifics of beyond "that was an oddly boring G-masscode system"? That's not remotely cost-effective for games development.
Unit-testing would have very easily and quickly caught such a simple bug like using or
instead of and
in such a check.
Given a sufficiently comprehensive test suite, yes. Since you can't write the tests only to catch the bugs you're going to implement, though, that needs to be pretty comprehensive. We've got a function that takes three input parameters (system coordinates) and has particular behaviour if those coordinates fall within a pre-defined cube.
So, that needs a minimum of four tests per dimension (one just either side of each boundary), to check that the faces are in the right place. That would be sufficient to catch the suppression cube bug, but you also want to check that you haven't accidentally implemented a suppression checkerboard, where (2,0) and (0,2) behave correctly, but (2,2) doesn't, so that needs another set of tests on the other 20 regions which don't have two of three zero-coordinates. 32 tests so far. Then you might want to test that there's not any inappropriate type conversion that might lead to integer overflows (so 0,0 and 0,1 are fine, but 0,32768 is broken again) which means a few more tests at greater distances, though you probably can get away with just doing two in each direction here.
So that's at least
38 unit tests to guarantee that one short inlinable bit of code is working to the spec, and I haven't covered every possible way it might not work yet.
What are the chances that someone who gets that short bit of code
wrong has written all 38 unit tests correctly?
How long, once that's all dealt with and this is all assembled into a full application, will it take to amend the code and correctly amend all unit tests so that when the internal playtest says "sorry, I can still see a bunch of imaginary bright stars from Sol, the suppression cube needs to be bigger", not only are the X/Y/Z boundaries changed in the code, but also it's correctly determined which unit tests failed because they're now testing against the wrong spec, and which ones failed because the code change was incorrect to either old or new spec? (And that's not just those 38 unit tests, but also some of the tests for the calling-site function, and whatever calls that, and so on, because they'll happen to also be using parameters which now don't work)
That's a lot of work for one line of functional code.
I like automated testing, I use it a lot myself, I probably spend at least as long on writing tests as writing the code. But my employers aren't going to pay for that even greater level of assurance any more than I'd pay £500 for Elite Dangerous 1.0 when it releases next year just to have the "no bugs" alternate timeline version.
That being, said, somehow I doubt that this check is in an especially time-critical part of the code
Without knowing the fine details it's hard to say, but "what is the primary star class of this system" (which is what the suppression cross very visibly affects) is probably something which needs to be calculated extremely quickly for map display, routing and skybox generation.