3 ms·

> You can always cherry-pick it back later and know that it works. Exactly, "this is what git is for". I think being uncomfortable tossing tested code is more

> You can always cherry-pick it back later and know that it works. Exactly, "this is what git is for". I think being uncomfortable tossing tested code is more of a reflection of the temperament of the person saying it than any truism about coders in general. If anything a little bit of a roadblock with test cases can be a good thing. "By deleting this test I am really certain I want to remove this feature". There's one place in my code base where I have extra tests in there, that I have to replace every time (it's snapshot-testing code-generating code), but that one little roadblock make me feel good because I know that the code that is being emitted is human-readable and easy for an end-user to debug.

breck 6y ago
> I have to replace every time (it's snapshot-testing code-generating code), Do you store your snapshots separately? One note for devs reading this: I think snapshot tests are very cool, but I recommend trying them as a very separate thing than unit tests (if you are not already doing that). I removed all snapshot tests from our unit testing pipeline and it's much better for it. Was very surprised that Jest doesn't have warnings that snapshot testing is a very different thing, and should not be intermixed with unit tests. Snapshot testing is sort of like code coverage, a great tool for telling you what to look for, and you should make it so that doing snapshot testing is easy, but the snapshots themselves should be stored outside of the main repo/main testing repo, and in their own thing. Not sure if you are doing that or not, but for anyone else looking at snapshot testing, this is a common mistake I see.
- dnautics 6y ago
  Normally I would agree for webapps but in this case, it's for generating low-level code. In general, It's only a mistake if it's burdensome. I only have about 30 of these tests, and they are for critical code (I want the end user to be able to review the test and be confident that the generated code doesn't contain memory leaks, etc). https://github.com/ityonemo/zigler/blob/3de4d6fe4def265b689bd21d3e0abad551bd2d50/test/unit/snapshot/adapter_test.exs#L234 https://github.com/ityonemo/zigler/blob/3de4d6fe4def265b689b...
  - breck 6y ago
    But can't you identify the signal of the input and output and write small test cases to test just the signal? Snaps test the signal + noise. They help alert you when either changed, which is helpful if you think you may be missing tests for the signal, but ideally you would just make sure all the signal is tested, and the snaps would be just a later, independent sanity check tool. Obviously you know the details and often once I learn the details I'm like "oh yeah in this case I see how the cost benefit makes sense". Just more speaking in generalities.
    - dnautics 6y ago
      > They help alert you when either changed that's exactly what I'm looking for =D. See response to sibling comment for why I also want to be able to review the full code layout.
  - breck 6y ago
    Taking a quick peak at the code, maybe more smaller functions with fewer params to make it more testable? Sorry that could be way off, just have limited time right now.
    - dnautics 6y ago
      I also do that, but since it's a LL programming language, there is coupling (a resource created in one place may be destroyed by different function).
hinkley 6y ago
I find that the way a test is written substantially affects people’s willingness to delete them, so while there is some truth to what you say, it’s not the entire picture. Near as I can guess, it’s related to the anchoring. I’m replacing a few tests with a new set of tests. How complicated should they be? The old test was simple, I should replace it with a simple test. I need six of them, six simple tests ain’t so bad. Nearly took me longer to think about it than to do it. If I write three line tests, the test quality tends to erode slowly. If I left sketchy tests, they turn to garbage disturbingly fast.

breck 6y ago

> I have to replace every time (it's snapshot-testing code-generating code), Do you store your snapshots separately? One note for devs reading this: I think snapshot tests are very cool, but I recommend trying them as a very separate thing than unit tests (if you are not already doing that). I removed all snapshot tests from our unit testing pipeline and it's much better for it. Was very surprised that Jest doesn't have warnings that snapshot testing is a very different thing, and should not be intermixed with unit tests. Snapshot testing is sort of like code coverage, a great tool for telling you what to look for, and you should make it so that doing snapshot testing is easy, but the snapshots themselves should be stored outside of the main repo/main testing repo, and in their own thing. Not sure if you are doing that or not, but for anyone else looking at snapshot testing, this is a common mistake I see.

dnautics 6y ago
Normally I would agree for webapps but in this case, it's for generating low-level code. In general, It's only a mistake if it's burdensome. I only have about 30 of these tests, and they are for critical code (I want the end user to be able to review the test and be confident that the generated code doesn't contain memory leaks, etc). https://github.com/ityonemo/zigler/blob/3de4d6fe4def265b689bd21d3e0abad551bd2d50/test/unit/snapshot/adapter_test.exs#L234 https://github.com/ityonemo/zigler/blob/3de4d6fe4def265b689b...
- breck 6y ago
  But can't you identify the signal of the input and output and write small test cases to test just the signal? Snaps test the signal + noise. They help alert you when either changed, which is helpful if you think you may be missing tests for the signal, but ideally you would just make sure all the signal is tested, and the snaps would be just a later, independent sanity check tool. Obviously you know the details and often once I learn the details I'm like "oh yeah in this case I see how the cost benefit makes sense". Just more speaking in generalities.
  - dnautics 6y ago
    > They help alert you when either changed that's exactly what I'm looking for =D. See response to sibling comment for why I also want to be able to review the full code layout.
- breck 6y ago
  Taking a quick peak at the code, maybe more smaller functions with fewer params to make it more testable? Sorry that could be way off, just have limited time right now.
  - dnautics 6y ago
    I also do that, but since it's a LL programming language, there is coupling (a resource created in one place may be destroyed by different function).

hinkley 6y ago

I find that the way a test is written substantially affects people’s willingness to delete them, so while there is some truth to what you say, it’s not the entire picture. Near as I can guess, it’s related to the anchoring. I’m replacing a few tests with a new set of tests. How complicated should they be? The old test was simple, I should replace it with a simple test. I need six of them, six simple tests ain’t so bad. Nearly took me longer to think about it than to do it. If I write three line tests, the test quality tends to erode slowly. If I left sketchy tests, they turn to garbage disturbingly fast.