7 ms·

Unit Tests are still underrated in my experience. It pains me when I see developers testing their functionality end to end, manually. Discover a formatting erro

• capableweb 5y ago
  Many developers seem to lack a focus on automation in the most basic sense of the word as well. While consulting, I see lots of backend developers constantly making a change, waiting for the server to reload with the new changes, switch to Postman/cURL/whatever, fire off their request and see if it's accurate. Rather than just having the request handler as a function that is under test with assertions, and have the test re-run on each change. So much time during a developers day is spent on just repetition, and they don't seem to care.
  • brtkdotse 5y ago
    Plenty of time to check Reddit while waiting for the server to reload.
• guzik 5y ago
  Once I wrote my third game in Unity, with unit tests coverage of about 80%. It was least buggy game in my entire career. It was also the hardest time as I had to start thinking more about creating testable components rather than messy spaghetti code I used to write before.
  • bobertlo 5y ago
    I’ve found that while I did spend a lot of time at first figuring out how to write testable code, I now am so much better at writing in this way that I am much more productive since everything has great test coverage. Saves me going back to modules I wrote 2 years ago to add features.
  • jeddy3 5y ago
    This is one of the best "side-effects" of testing, with the reasoning is that testable code is good code (as in modular, cohesive, etc...)
  • eXpl0it3r 5y ago
    Since testing in game development is very much underrated, it would be interesting to hear more about this. Was this just as a hobby or is the game available somewhere? And have you ever done a demo/talk about how you've approached unit testing with Unity?
    • gfxgirl 5y ago
      not unit testing but a good talk on one team's testing https://m.youtube.com/watch?v=m5zrfTFKf_E https://m.youtube.com/watch?v=m5zrfTFKf_E
  • HelloNurse 5y ago
    Games are likely to benefit significantly from unit tests: architecture is complex and likely to be improved by adding clean boundaries and layers for the sake of testability; supporting automation is likely to enable useful features (e.g. deterministic simulations); tests are likely to be meaningful and important.
    • HWR_14 5y ago
      Have you developed games at all, or are you just speaking from an armchair?
      • kelseyfrog 5y ago
        As a gamedev who writes unit tests, I agree with GP. Games benefit from unit tests. That, however, doesn't change the systemic incentives that prevent tests from being written. The ways that gamedev is budgeted/funded is a more important factor than more tests = a more stable/less buggy game.
        • HWR_14 5y ago
          What engine do you use that supports a unit test framework?
• pydry 5y ago
  It pains me when I see developers assiduously write unit tests for every line of their code and every single bug in the code ends up encoded in those unit tests so that they fail when the bug is fixed. Integration tests need to be the default and people need to learn when to use one or the other.
  • tjpnz 5y ago
    Are these bugs in the sense that the code's plain wrong or that the developer misunderstood the spec? Good unit tests (when written alongside the code they're testing) should go a long way towards preventing the former.
    • pydry 5y ago
      The latter. Also misunderstandings about APIs. IME these combined are usually something like 70% of all bugs so the ROI on unit tests is not particularly high. I find integration tests paired with BDD do a good job of catching "code plain wrong" bugs as well as misused APIs and misunderstood specs. They're harder to build and run slower but the ROI is still higher.
  • UK-AL 5y ago
    Because that seems like they're doing things backwards... You should know what result you want before you even start writing the code.
    • pydry 5y ago
      >You should know what result you want before you even start writing the code. In theory, but IME about 50% of bugs end up being specification bugs at the high level anyway. Once you drill down and start writing unit tests on lower levels to imitate higher level APIs that % only goes up.
• mrtksn 5y ago
  Unit tests are extremely boring for people who don't particularly like programming but do it anyway as means to an end. It's just another piece of code you are writing instead of releasing the dopamine of the finished product. It's anticlimactic. If you first write the test and then try to satisfy them(test driven development) can work to an extent as it can divide the large task into small pieces where you get a prize each time but it also alienates the developer from the larger picture, diminishing their value to the project since they no longer can put their intellectual output into the project.
  • idontwantthis 5y ago
    I find it makes programming so much more enjoyable both in an immediate gratification and long term way. More green checks = more dopamine Higher quality code = long term satisfaction.
    • mrtksn 5y ago
      Don't you think that it also alienates you from the projects? Green checks are green checks anyway, you can no longer put your input into the project and the best strategy for you becomes the minimal viable effort to earn a green check.
      • idontwantthis 5y ago
        > minimal viable effort to earn a green check That's literally the thesis of the Kent Beck book. I'm not some idiot copy and pasting `expect(true).toEqual(true)` I add functionality one test at a time. I get satisfaction of knowing it works as specified in the form of an increasing count of green checks. I don't understand why it would alienate me.
    • zozbot234 5y ago
      But there's nothing long term about unit tests, they only verify a particular version of the code and must be tweaked whenever that code is changed to return different results. The "happy green checks" that really help in the long term are comprehensive type checks, reflecting a reasonably stable underlying design.
• jseban 5y ago
  > Then I showed that a unit test can discover this Yeah but the catch is that in order for your code to be "testable" you have to rewrite it completely in a way that comes with large sacrifices, making it much more confusing, abstract, larger and much harder to work with, in every way except testing it.
  • Deukhoofd 5y ago
    I think the focus that everything should be testable is a wrong one, but almost every codebase has functionality that can be easily unit tested without major refactors. For everything else, integration tests can already help a lot.
    • catlifeonmars 5y ago
      Ideally, everything should be testable or replaceable. The non testable parts of your code have network effects on the testability of other parts of the code that are dependent on those parts. This is where dependency injection (e.g via a constructor or function parameters) really shines. I totally agree that if you have to choose (and usually you do, unless you have unlimited time and funding), choose to implement end to end integration tests first.
  • aequitas 5y ago
    Imho one of the benefits of unit testing is precisely that you have to write/refactor your code to make it more testable and in the process you uncover and fix flaws in lacking abstraction and isolation.
  • rootlocus 5y ago
    My experience is the exact opposite of this. Modular code that has well defined boundaries and responsibilities can be mocked and tested in isolation. It can also be reasoned about in isolation, reducing complexity. New functionality can be assigned to the proper module because each module has a well defined purpose.
  • esics6A 5y ago
    The simple verification aspect of unit tests makes writing code easier and more purposeful in my opinion. At a most basic level it's kind of like a small informal proof. When the code base get's complex and larger in size this is invaluable if unit tests are written correctly. Tests have to make sense and be written well just like any other piece of code. It also helps form thinking about test cases and logic before writing code. Before I used exhaustive unit tests I would just start writing code right away and often times this would result in constant refactoring as the code evolved or during debugging. But unit tests encouraged me to scaffold out abstract functions and write tests before implementing the code. It got me thinking about what the logic and workflows then implementing the functions meant having the tests pass as verification.
• josefx 5y ago
  > It pains me when I see developers testing their functionality end to end, manually On the other hand I know developers that only unit test. Hundreds of lines of mock code, dozens of tests. No documentation, no sample configuration for the final application and dozens of data races because the unit tests don't cover multi threading. But hey an unusable buggy mess is a net positive as long as it makes the test coverage statistic happy and that is one of those things reported to management. While a bit exaggerated one of the downsides of unit tests is that they quickly become part of a metric without regards for when they ad value.
  • AstralStorm 5y ago
    Hence why you need automated integration tests, where possible. Especially for regressions. They tend to have much higher value than pure unit tests.
    • rectang 5y ago
      I agree that automated integration tests typically offer higher ROI than equivalent unit tests written with mocks, because mock code is so difficult to write and fragile. I disagree with your assertion that integration tests offer higher value than unit tests in general. Don't judge all unit tests by mock code.
    • larkost 5y ago
      I will counter that integration tests tend to have a much bigger footprint: one test covers a lot more ground and so per line of code will catch more things. But, the failures from integration tests are often a lot harder to read. Even half-good unit tests tend to show exactly where the error is, and make the fix cycle much shorter. It is also much harder to write exhaustive integration tests for all of the inputs that might happen. I, as a long-term qa-ish person (I usually write testing systems) see real value in having a mixture of both system, integration (multiple systems), and unit tests, as well as end-to-end manual tests. Anything big enough needs all of these.
      • cush 5y ago
• bigDinosaur 5y ago
  Property based tests have the benefit of being fun to actually think about (as far as testing goes) and also often exposing more bugs than unit tests (which are usually more like sanity checks than exploring the boundary of what will break or turn weird your functions).
  • kelseyfrog 5y ago
    Property based tests have caught 10-100x the number of buggy edge-cases than the handwritten unit tests I could have come up with. The material gains of getting a combinatorial explosion of test cases from property composition is extremely underrated. However, there seems to be a general skepticism around property based tests in my experience. Any idea where it stems from?
    • dgb23 5y ago
      IMO, you have to code in a certain way to make them ergonomic or even worthwhile - which is also true for example tests. They have some overlap with example tests but have a different advantage. Example tests document function/interface usage and typical or historical errors/exceptions. Property based tests are more about data integrity and invariants.
    • oxff 5y ago
      It requires more mathematical / analytical thinking and code IME.