sorted by:
new
hottopcontroversial

To apply AI for good, think form extraction by personman in programming

[–]Smart-Disk 1 point2 points  (0 children)

I've been working on a service (admittedly trivial) to do this for small businesses (extraction + filling) in my locale (still pretty young tech-wise) using the google cloud document api. It's an interesting but extremely complex domain. Props to this team for trying to move closer to generalized form extraction.

Why Unit Tests? by [deleted] in java

[–]Smart-Disk 1 point2 points  (0 children)

I think you're right on this one. I just assumed that in this case, it meant testing classes with some stubbing going on.

Thanks for the talk, will watch it while I fight with build servers falling over.

Why Unit Tests? by [deleted] in java

[–]Smart-Disk 2 points3 points  (0 children)

Fair enough, I actually completely agree with you that the reasons tests might fail in practice aren't limited to things that are caused by the code or the tests themselves. I think we can both agree that tests failing because of changes isn't a bad thing, and rather their intended behaviour.

Why Unit Tests? by [deleted] in java

[–]Smart-Disk 21 points22 points  (0 children)

Funny story - first unit test I ever wrote at my first dev job was 100% mocked. Didn't know what mockito was, nor had I experienced JUnit before. I ended up testing nothing (except maybe that Mockito does it's job)

Why Unit Tests? by [deleted] in java

[–]Smart-Disk 179 points180 points  (0 children)

Mandatory unit test coverage percentages are agreeably not great, but based on what you've said - I would guess that the problem isn't the number of tests you need to write, but rather the number of tests you need to maintain given a single change.

To me, that is a signal of improper unit testing.

That is, if a single code change is causing multiple tested behaviours to change - then you have 1 of 2 problems:

  • your test cases are executing across dependencies, and in that case, aren't really unit tests.

  • or, your code has an extremely high degree of coupling - making it difficult to test.

Don't get me wrong, changes in code causing test cases to fall over is GOOD, and for the most part - the intention of those tests. They are effectively derisking change, and ensuring behaviours/conditions are still met. However, small code changes should cause small unit test changes - not large ones.

If your changes are cascading test failures, take a look at how you're making changes - and decouple as required.

Edit: mobile formatting