3 ms·

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 fo

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
  You on the other hand seem to completely ignore property based testing. Do look it up, it's not just for the FP crowd (even though it did come from there). Here's a primer: you think of some property that must hold for your object. Take a ring buffer for instance: if you push N elements, it must be of size N (assuming it's capacity is N or more). Then you generate random input, and use it to test your property. One property, thousands of tests. Once that's done, you can move on to some other property (like, the ring buffer must have FIFO behaviour). > to declare something as popular and influential as those two concepts "worse than useless" without bothering to understand them is, well, ballsy. It wouldn't be the first time our industry demonstrated blatant inadequacy —at least in hindsight. We're still a young field, popularity doesn't mean much. Maybe I would have considered mocking if I didn't know of property based testing. But the power difference between singular unit testing an property based tests is too great to ignore. The reason I call mocking frameworks "worse than useless" is because they turn you away from property based tests. If they were at least compatible with them… I'll allow one exception: if you can use the same mock with all the random input, or at least easily generate a moc per random input, then it wouldn't be too bad. It wouldn't be too good either, though. I'd rather test with the real stuff. If there's a regression, it will be revealed, with or without mocking. Actually, if some dependency isn't properly tested (distracted dev or something), not mocking it gives you a second chance at detecting bugs. On the other hand, have you ever seen a regression that would have gone undetected if you didn't used mocking? That doesn't seem plausible. The only use I see for mocks is to track down bugs once they are detected —by narrowing the search space. But I've never needed it in practice, with one possible exception: Lua. Are you using dynamic typing? That would explain a lot.
  - curun1r 9y ago
    I know what property based testing is. And it's not a substitute for unit testing. It's basically just a way of generating many tests from a single test template and is an alternative to example based testing. But it doesn't relate to what code you're testing, so what you're describing is still an integration test which serves a much different purpose from unit testing. Again, I think you just haven't had enough experience with unit testing and had that "aha" moment yet. It's not that I don't understand your point, I just doubt you have enough experience in testing strategies because you're trying to compare two things that aren't comparable. If I suggested your code use a function instead of a queue, you'd think I was ignorant and inexperienced because you can't replace a queue with a function...they're not concepts that can be swapped for one another. You suggesting property based testing instead of unit testing is likewise nonsensical. Unit testing and integration testing are different concepts of the same type. They cover what code gets tested. Property based testing is one of many strategies (example based testing, mutation testing, etc) that cover how code gets tested. Choosing to write unit tests instead of integration tests does not preclude the use of property based testing or any other technique that covers how you test code. As I stated before, if you were to use property based testing at the unit test level, it would be all the more powerful because you'd get that same exponential coverage just with significantly larger number of effective tests per unit of code. From the A, B, C dependency graph example, if you used property based testing to test A thousands of times, B thousands of times and C thousands of times, you'd effectively be testing thousands times thousands times thousands (aka billions) of different scenarios. And you'd still be able to use mocks because mocks are created in test code and can be as dynamic as you need them to be. I've done testing in many languages, both static and dynamic. Dynamic languages, thanks to the lack of static type checking, often don't need a mocking framework because the language is flexible enough that you can swap in a mock-like object at runtime. But the concepts are the same. And there really is a ton of value in testing code you've written in isolation. It's the testing equivalent of separation of concerns. And just like some developers never grok the single responsibility principle, some developers never grok the need to test code in isolation. You've obviously understood how to encapsulate your concerns based on the design you implemented. And yet the testing strategy you described is the opposite...trying to test everything at once rather than focusing on each test covering one specific bit of code.

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
You on the other hand seem to completely ignore property based testing. Do look it up, it's not just for the FP crowd (even though it did come from there). Here's a primer: you think of some property that must hold for your object. Take a ring buffer for instance: if you push N elements, it must be of size N (assuming it's capacity is N or more). Then you generate random input, and use it to test your property. One property, thousands of tests. Once that's done, you can move on to some other property (like, the ring buffer must have FIFO behaviour). > to declare something as popular and influential as those two concepts "worse than useless" without bothering to understand them is, well, ballsy. It wouldn't be the first time our industry demonstrated blatant inadequacy —at least in hindsight. We're still a young field, popularity doesn't mean much. Maybe I would have considered mocking if I didn't know of property based testing. But the power difference between singular unit testing an property based tests is too great to ignore. The reason I call mocking frameworks "worse than useless" is because they turn you away from property based tests. If they were at least compatible with them… I'll allow one exception: if you can use the same mock with all the random input, or at least easily generate a moc per random input, then it wouldn't be too bad. It wouldn't be too good either, though. I'd rather test with the real stuff. If there's a regression, it will be revealed, with or without mocking. Actually, if some dependency isn't properly tested (distracted dev or something), not mocking it gives you a second chance at detecting bugs. On the other hand, have you ever seen a regression that would have gone undetected if you didn't used mocking? That doesn't seem plausible. The only use I see for mocks is to track down bugs once they are detected —by narrowing the search space. But I've never needed it in practice, with one possible exception: Lua. Are you using dynamic typing? That would explain a lot.
- curun1r 9y ago
  I know what property based testing is. And it's not a substitute for unit testing. It's basically just a way of generating many tests from a single test template and is an alternative to example based testing. But it doesn't relate to what code you're testing, so what you're describing is still an integration test which serves a much different purpose from unit testing. Again, I think you just haven't had enough experience with unit testing and had that "aha" moment yet. It's not that I don't understand your point, I just doubt you have enough experience in testing strategies because you're trying to compare two things that aren't comparable. If I suggested your code use a function instead of a queue, you'd think I was ignorant and inexperienced because you can't replace a queue with a function...they're not concepts that can be swapped for one another. You suggesting property based testing instead of unit testing is likewise nonsensical. Unit testing and integration testing are different concepts of the same type. They cover what code gets tested. Property based testing is one of many strategies (example based testing, mutation testing, etc) that cover how code gets tested. Choosing to write unit tests instead of integration tests does not preclude the use of property based testing or any other technique that covers how you test code. As I stated before, if you were to use property based testing at the unit test level, it would be all the more powerful because you'd get that same exponential coverage just with significantly larger number of effective tests per unit of code. From the A, B, C dependency graph example, if you used property based testing to test A thousands of times, B thousands of times and C thousands of times, you'd effectively be testing thousands times thousands times thousands (aka billions) of different scenarios. And you'd still be able to use mocks because mocks are created in test code and can be as dynamic as you need them to be. I've done testing in many languages, both static and dynamic. Dynamic languages, thanks to the lack of static type checking, often don't need a mocking framework because the language is flexible enough that you can swap in a mock-like object at runtime. But the concepts are the same. And there really is a ton of value in testing code you've written in isolation. It's the testing equivalent of separation of concerns. And just like some developers never grok the single responsibility principle, some developers never grok the need to test code in isolation. You've obviously understood how to encapsulate your concerns based on the design you implemented. And yet the testing strategy you described is the opposite...trying to test everything at once rather than focusing on each test covering one specific bit of code.