data-plumbing-for-corporations tends to be able to be done in a way that’s easily testable, but also most people get paid to bolt on new shit onto old shit and spending time on “done” code is discouraged so once they fall behind on writing tests while developing the new shit those tests will never be written.
and bad developers that won’t write tests no matter what actually do exist.
If I actually did have that kind of job, the tests-first philosophy would sound very appealing. Actually, build the stack so you don’t have a choice - the real code should just be an instantiation of plumbing on generic variables with certain expected statistical properties. You can do that when correctly processing unpredictable but repetitive stuff is the name of the game, and I expect someone does.
Unit tests typically test rather fine grained, but coming up with the structure of the grain is 80% of the work. Often enough you end up with code that’s structured differently than initially thought, because it turns out that this one class needs to be wrapped, and this annotation doesn’t play nice with the other one when used on the same class, etc etc.
Because you don’t know what you’ll need that wrapper beforehand, that’s my entire point.
Unless you’re only doing trivial changes, the chances are very high that you won’t be able to design the class structure. Or, you end up essentially writing the code to be able to write the tests, which kind of defeats the purpose.
That’s kind of the whole philosophy, though. The tests are the main way you understand what you’re doing, the working code is just an addition on top of that. Presumably, there’s a way to do that without repeating yourself - although I’m not turning up much on a quick look.
At a certain level of detail, tests just become a debugger, right?
I’m thinking of something like an implementation of Strassen’s algorithm. It’s all arithmetic; you can’t really check for macro correctness at a micro point without doing a similar kind of arithmetic yourself, which is basically just writing the same code again. It resembles nothing other than itself.
Yeah, you definitely run fixed tests on the whole thing. But when it returns indecipherable garbage, you’ve got to dive in in more detail, and at that point you’re just doing breakpoints and watchpoints and looking at walls of floating point values.
I suppose Strassen’s is recursive, so you could tackle it that way, but for other numerical-type things there is no such option.
Especially then I’d test the shit out of everything? I’m getting paid for writing correct software.
data-plumbing-for-corporations tends to be able to be done in a way that’s easily testable, but also most people get paid to bolt on new shit onto old shit and spending time on “done” code is discouraged so once they fall behind on writing tests while developing the new shit those tests will never be written.
and bad developers that won’t write tests no matter what actually do exist.
If I actually did have that kind of job, the tests-first philosophy would sound very appealing. Actually, build the stack so you don’t have a choice - the real code should just be an instantiation of plumbing on generic variables with certain expected statistical properties. You can do that when correctly processing unpredictable but repetitive stuff is the name of the game, and I expect someone does.
Tests first is only good in theory.
Unit tests typically test rather fine grained, but coming up with the structure of the grain is 80% of the work. Often enough you end up with code that’s structured differently than initially thought, because it turns out that this one class needs to be wrapped, and this annotation doesn’t play nice with the other one when used on the same class, etc etc.
Can’t you just add the wrapper to the test as well, if it’s easy to do in the actual code?
If you have to ask “can’t you just” the answer is almost always no.
Well, yeah, but I was kind of hoping you’d explain why.
Because you don’t know what you’ll need that wrapper beforehand, that’s my entire point.
Unless you’re only doing trivial changes, the chances are very high that you won’t be able to design the class structure. Or, you end up essentially writing the code to be able to write the tests, which kind of defeats the purpose.
That’s kind of the whole philosophy, though. The tests are the main way you understand what you’re doing, the working code is just an addition on top of that. Presumably, there’s a way to do that without repeating yourself - although I’m not turning up much on a quick look.
At a certain level of detail, tests just become a debugger, right?
I’m thinking of something like an implementation of Strassen’s algorithm. It’s all arithmetic; you can’t really check for macro correctness at a micro point without doing a similar kind of arithmetic yourself, which is basically just writing the same code again. It resembles nothing other than itself.
And who actually writes tests like that?
I mean, do you think tests do the calculations again? You simply have well defined input and known, static output. That’s it.
Yeah, you definitely run fixed tests on the whole thing. But when it returns indecipherable garbage, you’ve got to dive in in more detail, and at that point you’re just doing breakpoints and watchpoints and looking at walls of floating point values.
I suppose Strassen’s is recursive, so you could tackle it that way, but for other numerical-type things there is no such option.