7 ms·

I'm not going to comment on how you should have done it without seeing the code. You can throw out terms like reactor base class, MWSR (which I've never heard o

I'm not going to comment on how you should have done it without seeing the code. You can throw out terms like reactor base class, MWSR (which I've never heard of but am assuming is just an MPSC using non-standard terminology) and ring buffer, but that's not enough to go on to talk about your specific situation. Moreover, it sounds like you're using C++ which isn't a language I've spent much time coding in, so I'm ill equipped to talk about mocking frameworks available to you. > Allow me to laugh at your measly 27 from atop my high horse If you're going make snide comments, I'll stop this discussion. Suffice it to say you missed the point. 27 isn't just a number, it's a number arrived at by applying an exponent. Exponents get really big in a hurry. As the author of a crypto suite, I'd expect you to pay exponents a bit more respect. Testing 3 different cases per dependency gives you 27. Testing 10 gives you 1000. Property based testing is not a substitute for this kind of coverage. It is, however, complementary. It allows you to increase the base number which is raised to the exponent. > I could have mocked my ring buffer without writing another full featured ring buffer. Mocking looks a bit ridiculous in this case. It's safe to assume from this comment that you don't really understand mocking. Mocks aren't an implementation of an interface to be used in tests. Mocks verify that they were called in an expected way/order and give back the appropriate value. They don't actually do anything. They're highly coupled with each test case. This is why most mocking frameworks dynamically generate the mock per-test and let you simply verify the call(s) and tell it what to return. > This feels backwards It's absolutely not backwards. The main purpose of a test suite is to find a very specific type of bug...regressions. It's not to avoid other sorts of bugs other than the fact that forcing developers to write tests will force them to think about their code in ways that make them realize they missed something during implementation. But the most important thing is to be able to rely on them to tell you when you've broken something that previously worked. Every single time I've come to a code base that was either missing tests or relied too heavily on integration tests, we've had a significant problem with regressions and, over time, developers shied away from making significant changes to the code base because they were afraid to break it. And the result is that ossification that you try not to achieve. But when you see a code base with a commitment to unit tests, you also see one where developers are free to make the necessary radical changes without fear of breaking existing functionality. They make the changes, run the suite and let it tell them everywhere they forgot to change, whether that be in application code or test code.

loup-vaillant 9y ago
Multiple Writer Single Reader queue. Each on its own thread. A reactor is just an actor that read input from such a queue, then reacts to it. It's the basis for an actor model. --- Yeah, C++. I don't know of any mocking framework there, and I'm not going to look for one —my current opinion on that stuff veers towards "worse than useless". (You just reinforced that notion by the way, see below.) --- 27 is a number you arrived by fantasizing about how mocking make your tests more thorough than they actually are —and you're not even testing under real conditions! Just an outsider's scepticism. Your exponent is also driven by the number of dependencies, whose increasing number requires an exponentially growing number of tests. Property based testing on the other hand (search for "QuickCheck") generates as many random tests as one feels like using. (Of course, one has to test for several properties, but then each property can be thoroughly tested.) > It's safe to assume from this comment that you don't really understand mocking. Indeed, thanks for the explanation. But that just showed mocs are fundamentally incompatible with property based testing: I'd need to generate a moc for each random test case. Nope. I'm keeping my property based tests, they're much more powerful. --- So you were talking about using your test suite like a type system on steroids. Good. Just keep in mind that there's a stark difference between maintaining a good test suite, and bending the code around some narrow idea of testability. I only do the former. Oh, and I tend to write tests after I write the code. Property based test don't make sense before the module is done anyway. A quick note about unit vs integration test: in our little A->B->C example, testing C, then B (without mocs), then A (without mocs) are all unit tests in my book. A few internal dependencies aren't going to change that. By the way, I'm talking about compile-time dependency, of the kind that don't involve runtime shared state. Shared state open a whole 'nother can of worm, and I do see the need to separate unit and integration tests for those. (I also see the need to avoid shared state as much as possible.)
- curun1r 9y ago
  I'm not going to try to refute what you've said since you've clearly demonstrated a lack of understanding of unit testing (your "book" isn't correct) and mocking and a lack of willingness to be convinced. Going point-by-point would just be restating things I've said above. I'll just say that to declare something as popular and influential as those two concepts "worse than useless" without bothering to understand them is, well, ballsy. Incidentally, here's two C++ mocking frameworks found from Google, in case you're more open minded than I'm giving you credit for: https://github.com/google/googletest/tree/master/googlemock https://github.com/google/googletest/tree/master/googlemock (part of https://github.com/google/googletest https://github.com/google/googletest) https://github.com/eranpeer/FakeIt https://github.com/eranpeer/FakeIt

loup-vaillant 9y ago

Multiple Writer Single Reader queue. Each on its own thread. A reactor is just an actor that read input from such a queue, then reacts to it. It's the basis for an actor model. --- Yeah, C++. I don't know of any mocking framework there, and I'm not going to look for one —my current opinion on that stuff veers towards "worse than useless". (You just reinforced that notion by the way, see below.) --- 27 is a number you arrived by fantasizing about how mocking make your tests more thorough than they actually are —and you're not even testing under real conditions! Just an outsider's scepticism. Your exponent is also driven by the number of dependencies, whose increasing number requires an exponentially growing number of tests. Property based testing on the other hand (search for "QuickCheck") generates as many random tests as one feels like using. (Of course, one has to test for several properties, but then each property can be thoroughly tested.) > It's safe to assume from this comment that you don't really understand mocking. Indeed, thanks for the explanation. But that just showed mocs are fundamentally incompatible with property based testing: I'd need to generate a moc for each random test case. Nope. I'm keeping my property based tests, they're much more powerful. --- So you were talking about using your test suite like a type system on steroids. Good. Just keep in mind that there's a stark difference between maintaining a good test suite, and bending the code around some narrow idea of testability. I only do the former. Oh, and I tend to write tests after I write the code. Property based test don't make sense before the module is done anyway. A quick note about unit vs integration test: in our little A->B->C example, testing C, then B (without mocs), then A (without mocs) are all unit tests in my book. A few internal dependencies aren't going to change that. By the way, I'm talking about compile-time dependency, of the kind that don't involve runtime shared state. Shared state open a whole 'nother can of worm, and I do see the need to separate unit and integration tests for those. (I also see the need to avoid shared state as much as possible.)

curun1r 9y ago
I'm not going to try to refute what you've said since you've clearly demonstrated a lack of understanding of unit testing (your "book" isn't correct) and mocking and a lack of willingness to be convinced. Going point-by-point would just be restating things I've said above. I'll just say that to declare something as popular and influential as those two concepts "worse than useless" without bothering to understand them is, well, ballsy. Incidentally, here's two C++ mocking frameworks found from Google, in case you're more open minded than I'm giving you credit for: https://github.com/google/googletest/tree/master/googlemock https://github.com/google/googletest/tree/master/googlemock (part of https://github.com/google/googletest https://github.com/google/googletest) https://github.com/eranpeer/FakeIt https://github.com/eranpeer/FakeIt