Unit tests as documentation

(www.thecoder.cafe)

94 points thunderbong | 1 comments | 17 Oct 24 17:22 UTC | HN request time: 0s | source

Show context

kubectl_h ◴[17 Oct 24 18:38 UTC] No.41872436[source]▶

I am starting to notice more and more unit tests in my org are written by AI -- I'm guessing usually after the implementation. I know this because I have, guiltily, done it and can tell when someone else has done it as well. I don't think anything can be done about this technically so it probably needs to be something discussed socially within the team.

replies(1): >>41872516 #

_thisdot ◴[17 Oct 24 18:44 UTC] No.41872516[source]▶

>>41872436 #

What is wrong with this? Tests involve a lot of hardcoding and mocking. I see this as an excellent use case for AI.

replies(1): >>41872801 #

1. JonChesterfield ◴[17 Oct 24 19:10 UTC] No.41872801[source]▶

>>41872516 #

Generating tests that match the implementation doesn't tell you the implementation is doing the right thing. If it isn't, changing the implementation will break the tests, which in the best case wastes time and in the worst means the bugfix is abandoned.

I deeply hate "regression tests" that turn red when the implementation changes, so you regenerate the tests to match the new implementation and maybe glance at the diff, but the diff is thousands of lines long so really it's not telling you anything other than "something changed".

↑