4 ms·
TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will t
by norswap 9y ago
TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will turn up, so it's hard to anticipate the interface in my tests (or it leads to a lot of wasted).
Nowadays I mostly test with "redundant random generation testing": generate random but coherent input, run logic, then... Either I can reverse the logic, and I do that and verify that I get back the original input. Or I can't and then I simply write a second implementation (as simple as possible, usually extremely inefficient). This finds bugs that classical unit and integration testing would never find.
- neuromantik8086 9y agoMy former lab tried to use TDD. I've come to the impression that it's not the right approach for science / prototyping and just bogs you down. I don't think that science should eschew testing completely- I just think that something like your "redundant random generation testing" is more in line with what needs to go on. The trickier issue is changing your lab culture so that it actually understands the need to run tests of some kind consistently / with discipline.
- daxfohl 9y agoThis is funny, because as a consultant, I think to myself "TDD really doesn't work for me, because I've got so many 3rd-party dependencies that I have to mock out in my tests (which often makes unit tests seem more like a test of your mocks than of your actual application); TDD must really be best for researchy things where they don't have to deal with those problems".
- bluGill 9y agoWhy are you mocking those 3rd party things? I find in most cases I can test with the 3rd party thing in an integration style test. When the data I'm testing is trivial those 3rd party things can give me an answer in less than a millisecond and so my whole test is fast enough. I find that even when I need to do things like database query that setting up a database with fake data is enough that mocking the database isn't worth it. As a bonus if there is a bug in the 3rd party code I'll find it before we go to production. My boss doesn't want me to point fingers and some 3rd party code when we are losing millions of dollars because of a software bug: he doesn't want to lose those millions of dollars in the first place!
- daxfohl 9y agoSee my other comment on this thread: https://news.ycombinator.com/item?id=14668402 https://news.ycombinator.com/item?id=14668402