6 ms·

> Except we have no almost no unit tests because > 1) Most of the devs don't know how to write unit tests > 2) Most of the devs don't know hot to write code t

> Except we have no almost no unit tests because > 1) Most of the devs don't know how to write unit tests > 2) Most of the devs don't know hot to write code that is testable, even if they could write the actual unit tests. Sounds really familiar... I'd like to add the following one: > 3) Cannot make the distinction between code that needs unit testsand code that does not need unit tests

fatoons21 8y ago
I'm new to development, would you recommend any resource out there that covers points 1) 2) and 3)? Thanks
- AllegedAlec 8y ago
  To be fair: much of it it practice and prior knowledge. I personally found the book Pragmatic Unit Testing helpful, as well as the Clean Code chapter on unit tests. Others may be more able to find you more readily available sources.
- TeMPOraL 8y ago
  I'm old to development, and would like to ask for the same thing. But something beyond "Pragmatic Unit Testing". You see, I've read that. I've read one other book on unit tests too, and been on 2-day long training in TDD, and spent many hours trying to write unit tests, and yet the skill still eludes me. It's like I have a blind spot there, because I can't for the best of me figure out how to test most of the code I write. In the projects I'm working on, I find roughly 10% of the code to be unit-testable even in principle. That's the core logic, the tricky parts - like the clever pathfinding algorithm I wrote for routing arrows in diagrams, or the clever code that diffs configurations to output an executable changeset (add this, delete that, move this there...). This I usually write functional-style (regardless of language), I expect specific inputs and outputs, so I can test such code effectively. Beyond that, I can also test some trivial utilities (usually also written in functional style). But the remaining 80-90% of any program I work on turns out to be a combination of: - code already tested by someone else - external dependencies - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people I'm having trouble even imagining how to unit-test the three things above, and it's not something covered in unit testing books, tutorials or courses I've seen - they all focus on the basics, like assertions and red-green-refactor, which are the dumb part of writing test. I'm looking for something for the difficult part - how to test the three categories of code I mentioned above.
  - vishalh 8y ago
    > - code already tested by someone else - external dependencies You test for whether the integration works correctly, for example if you use a library for computation you will test whether your function which uses the library is producing the expected result > - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) Here again you do some integration testing, for example when handling database operations, you can setup a test to load fake data in the database, run operations on this fake data and compare the results, and then purge the fake data. > - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people This sort of testing has become much more common for web apps and mobile apps, there are two things being tested one is whether the interface loads correctly under different conditions(device types, screen resolutions etc) this is tested by comparing the image for the 'correct' configuration with the test results, the other thing is whether the interface behaves correctly for certain test interactions - this is tested by automating a set of interactions using an automation suit and then checking whether the interface displays/ouputs the correct result.
  - cellularmitosis 8y ago
    This "Architecture: the lost years" keynote from uncle bob was helpful for me: https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 I've also struggled with this notion of "untestable" code. Untestable code seems to usually be a big pile of function calls. Testable code seems to be little islands of functionality which are connected by interfaces where only data is exchanged. Practically, this seems to be about shying away from interfaces which look like 'doThis()', 'doThat()', and more like 'apply(data)'. Less imperative micro-management and more functional-core/imperative-shell. Edit: a network analogy might be: think about the differences between a remote procedure call API vs. simply exchanging declarative data (REST).
  - icc97 8y ago
    The only thing that smelled like a path to enlightenment seemed to be Haskell's QuickCheck [0]. It's actually going out searching for bugs for me, rather than me having to pretend like I can think of all the failure cases. I haven't implemented it in a project yet though so I don't know how much easier it is than unit testing. [0]: https://hackage.haskell.org/package/QuickCheck https://hackage.haskell.org/package/QuickCheck
frobozz 8y ago
I'd like to add: 4) Don't know how to mock effectively I've seen three flavours of this one: - tests that take forever because they don't mock a slow external process that gets called 100s of times in the suite. - tests that randomly break because someone left a file in /tmp/ or some other lack-of-isolation mystery. - tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested.
- polygotdomain 8y ago
  >tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested. Can you expand on this a bit? I've always worked under the impression that tests should be focused on testing a narrow slice of code. So if my SUT has some dependencies, those will be mocked with the expected result from the dependency, and possibly even with the expected parameters in the arguments. The asserts will check the result from the SUT, but also that the expected method on the mock was called. This way, I'm just testing the code for the SUT, nothing more.
  - merlincorey 8y ago
    I'm not the GP in question, but I have worked on code that I think fits this phrasing. In that project's case, 99% of tests were mocks where the only thing being tested was whether or not the mocked function got called the expected number of times or with expected arguments. So the many thousands of tests ran very quickly, and over 90% of the code was covered by tests; however, nothing was actually being functionally tested in those cases. In other words, the tests ran like shit off a shiny shovel.
    - frobozz 8y ago
      Yes. This. What then happens is that the mocked out functions change what they return, or the order of what they do inside (e.g so that for a given set of inputs now throws a different exception). Someone forgets to update the mocks. All the tests continue to pass, even though none of the conditions are actually possible in the program.

fatoons21 8y ago

I'm new to development, would you recommend any resource out there that covers points 1) 2) and 3)? Thanks

AllegedAlec 8y ago
To be fair: much of it it practice and prior knowledge. I personally found the book Pragmatic Unit Testing helpful, as well as the Clean Code chapter on unit tests. Others may be more able to find you more readily available sources.
TeMPOraL 8y ago
I'm old to development, and would like to ask for the same thing. But something beyond "Pragmatic Unit Testing". You see, I've read that. I've read one other book on unit tests too, and been on 2-day long training in TDD, and spent many hours trying to write unit tests, and yet the skill still eludes me. It's like I have a blind spot there, because I can't for the best of me figure out how to test most of the code I write. In the projects I'm working on, I find roughly 10% of the code to be unit-testable even in principle. That's the core logic, the tricky parts - like the clever pathfinding algorithm I wrote for routing arrows in diagrams, or the clever code that diffs configurations to output an executable changeset (add this, delete that, move this there...). This I usually write functional-style (regardless of language), I expect specific inputs and outputs, so I can test such code effectively. Beyond that, I can also test some trivial utilities (usually also written in functional style). But the remaining 80-90% of any program I work on turns out to be a combination of: - code already tested by someone else - external dependencies - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people I'm having trouble even imagining how to unit-test the three things above, and it's not something covered in unit testing books, tutorials or courses I've seen - they all focus on the basics, like assertions and red-green-refactor, which are the dumb part of writing test. I'm looking for something for the difficult part - how to test the three categories of code I mentioned above.
- vishalh 8y ago
  > - code already tested by someone else - external dependencies You test for whether the integration works correctly, for example if you use a library for computation you will test whether your function which uses the library is producing the expected result > - code bureaucracy, which forms vast majority of the program - that is, including/injecting/managing dependencies, moving data around, jumping through and around abstraction layer; this I believe is untestable in principle, unless I'm willing to test code structure itself (technically doable for my Lisp projects...) Here again you do some integration testing, for example when handling database operations, you can setup a test to load fake data in the database, run operations on this fake data and compare the results, and then purge the fake data. > - the user interface, the other big part, which is also hilariously untestable, and rarely worth testing automatically, as any regression there will be immediately noticed and reported by real people This sort of testing has become much more common for web apps and mobile apps, there are two things being tested one is whether the interface loads correctly under different conditions(device types, screen resolutions etc) this is tested by comparing the image for the 'correct' configuration with the test results, the other thing is whether the interface behaves correctly for certain test interactions - this is tested by automating a set of interactions using an automation suit and then checking whether the interface displays/ouputs the correct result.
- cellularmitosis 8y ago
  This "Architecture: the lost years" keynote from uncle bob was helpful for me: https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 I've also struggled with this notion of "untestable" code. Untestable code seems to usually be a big pile of function calls. Testable code seems to be little islands of functionality which are connected by interfaces where only data is exchanged. Practically, this seems to be about shying away from interfaces which look like 'doThis()', 'doThat()', and more like 'apply(data)'. Less imperative micro-management and more functional-core/imperative-shell. Edit: a network analogy might be: think about the differences between a remote procedure call API vs. simply exchanging declarative data (REST).
- icc97 8y ago
  The only thing that smelled like a path to enlightenment seemed to be Haskell's QuickCheck [0]. It's actually going out searching for bugs for me, rather than me having to pretend like I can think of all the failure cases. I haven't implemented it in a project yet though so I don't know how much easier it is than unit testing. [0]: https://hackage.haskell.org/package/QuickCheck https://hackage.haskell.org/package/QuickCheck

frobozz 8y ago

I'd like to add: 4) Don't know how to mock effectively I've seen three flavours of this one: - tests that take forever because they don't mock a slow external process that gets called 100s of times in the suite. - tests that randomly break because someone left a file in /tmp/ or some other lack-of-isolation mystery. - tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested.

polygotdomain 8y ago
>tests that run like shit off a shiny shovel, because everything is mocked, meaning that nothing is actually tested. Can you expand on this a bit? I've always worked under the impression that tests should be focused on testing a narrow slice of code. So if my SUT has some dependencies, those will be mocked with the expected result from the dependency, and possibly even with the expected parameters in the arguments. The asserts will check the result from the SUT, but also that the expected method on the mock was called. This way, I'm just testing the code for the SUT, nothing more.
- merlincorey 8y ago
  I'm not the GP in question, but I have worked on code that I think fits this phrasing. In that project's case, 99% of tests were mocks where the only thing being tested was whether or not the mocked function got called the expected number of times or with expected arguments. So the many thousands of tests ran very quickly, and over 90% of the code was covered by tests; however, nothing was actually being functionally tested in those cases. In other words, the tests ran like shit off a shiny shovel.
  - frobozz 8y ago
    Yes. This. What then happens is that the mocked out functions change what they return, or the order of what they do inside (e.g so that for a given set of inputs now throws a different exception). Someone forgets to update the mocks. All the tests continue to pass, even though none of the conditions are actually possible in the program.