Testing can be fun, actually

19 points by bugsmith

berserk

Writing tests is boring.

I'm interested to hear how many people agree with this.

I personally find writing tests to be a lot of fun and look forward to it when programming. Seeing lots of green (and looking forward to seeing lots of green) really scratches an itch in my brain.

aarroyoc

I like writing tests, but I find tedious creating the whole setup that you need to build effective tests. Once a project has it, it's easy, but if it has nothing then I need to breath deeply
- giacomo_cavalieri
  
  Ah I get that feeling! I remember once being tasked to bring this work codebase up to 80% coverage and it had no tests at all 😅
- technomancy
  
  I think this is really common when tests are considered an afterthought. This is a sign that no one has taken the tests seriously enough to think thru what kind of abstractions they need to make their setup not be tedious and painful.
- steinuil
  
  Yup. I usually have an idea of the situation that I want to test, but the machinery to set that up is often very complicated and (in the case of the Python tests at my workplace) completely untyped and often not composable. Most of the time I end up copying the setup code from another test without completely understanding it and be content with jj splitting the test from my change and run it before, check that it fails, and run it after, and check that it passes.
Lanny

I’m definitely in the “tests are boring and I wouldn’t do them if I didn’t have to” camp.

I can understand the mentality of people who enjoy testing, occasionally I even get to write a test of some well behaved thing like a nice pure function of and to value types and I kinda get a kick out of trying to devise a table of inputs and outputs with sneaky little edge cases, then making sure they’re all covered. But I often find the things I work on aren’t like this, there’s a big messy API, the thing under test has side effects, I end up having to make my test very beholden to implementation details rather than the actual interface (basically all mocking) so I feel like many tests that get written are more a “test thing never gets modified again” sort of thing than actual evidence of correctness and that’s where the whole exercise starts to feel like tedium
- mpweiher
  
  Do you test first or test after?
  - spc476
    
    I'm not @Lanny (who I agree with) but I test after. Writing tests before coding is just alien to my way of thinking.
- giacomo_cavalieri
  
  Hello, author here! Yeah I agree, it's a bit tongue in cheek to appeal to a larger crowd but I myself am in the "mostly likes writing tests" camp 😁
- icholy
  
  Writing tests is fine if the code is written in a testable way. Otherwise it's hell.
- spc476
  Writing tests is boring.
  
  Personally, I've found I like table-driven tests more than writing tests (as code). Something like:
  
  output1 input1a input1b input1c output2 input2a input2b input2c output3 input3a input3b NULL
  
  but I seem to be in the minority in this case. I also find mocking to be problematic and the complaint about that post was that it involved too much testing.
bmh

I quite liked the usage of snapshots for testing the help text. I think it works well because the text content is diff-able and very easy to parse as a human. In my opinion, this is where snapshot tests excel.

Having used snapshot tests extensively in UI contexts, my experience has been I put little to no trust in snapshots tests (particularly of the DOM). I find that snapshot libraries have this “handy” feature to accept the changes and this makes it too easy to accept changes without reviewing why the test failed. Of course, this might be a process problem, but I think still it’s a weakness of snapshot tests in general. Subtle but incorrect changes to the output can be easy to disregard.

I’ve found myself to trust unit tests with the classic setup and assertions because it requires a developer to think harder about what is causing the test to fail instead of being given an easy path of accepting the new output.
- Lanny
  
  This is generally my experience in most team contexts as well. I will say that UI snapshot testing on very small team projects or personal projects where you can reasonably expect every person making changes understands every piece of the UI and what should or shouldn’t be changing in snapshots when a given piece of code changes, then it’s worked well for me.
  
  Also often the value isn’t so much “I rigorously looked at the snapshot diff and confirmed the change was right or wrong” as “wait, why did my change in a util file used by foo cause bar’s snapshot to change?”. That is knowing what wiggled at all is often more useful than exactly what changed, if for no other reason than it’s a good reminder to go look at everything that changed and confirm that you didn’t make some assumption that gets violated in some far flung context.
- giacomo_cavalieri
  
  Having used snapshot tests extensively in UI contexts...
  
  Yeah I think snapshot testing UIs is really not that nice, you get that feeling of "just accept anything and everything". I snapshot testing really shines when testing "regular" code that can benefit from being displayed in some pretty string version
seafoamteal

I first encountered snapshot tests on the Gleam compiler, which is mentioned in the article, and I really like them now! The cool formatting that Giacomo shows off in the article definitely makes the snapshots easier to review, and another benefit is that your test files are much more focused because they only contain the test code and not hundreds/thousands of lines of expected output.
- giacomo_cavalieri
  
  I discovered snapshot testing thanks to the Gleam compiler too! My first reaction was "how come I've never heard of this before, this rocks"
simonw
I love snapshot testing. I started doing it manually six years ago using Black and pytest, then I found Syrupy which lets you write tests like this:
```
def test_two(snapshot):
    assert snapshot == {"foo": [1, 2, 3], "bar": {"baz": "qux"}}
```
That snapshot is a pytest fixture which magically resolves to the captured snapshot for the test in question. You can update it using pytest --snapshot-update - the snapshot is serialized to disk in the tests/__snapshots__ folder.

I've also used inline-snapshot which is a little more magic - it rewrites your test files directly to match the snapshot, as seen here. You don't even need a fixture with that one, you just import the snapshot() function and use it like this:
```
    assert response_dict == snapshot(
        {
            "content": "Red green geometric shapes",
            "role": "assistant",
            "finish_reason": "stop",
```