Re:It's probably time to stop recommending Clean Code (2020)
by therealdrag0 on Tuesday May 25, 2021 @01:13PM
(#27279493)
Oh god. Or just the tests that are walls of text, mixes of mocks and initializers and constructors and method calls.
Like good god, extract that boiler plate into a function. Use comments and white space to break it up and explain the workflow.
Re:It's probably time to stop recommending Clean Code (2020)
by hinkley on Tuesday May 25, 2021 @05:06PM
(#27282658)
I have a couple people who use a wall of boiler plate to do something 3 lines of mocks could handle, and not couple the tests to each other in the process.
Every time I have to add a feature I end up rewriting the tests. But you know, code coverage, so yay.
Re:It's probably time to stop recommending Clean Code (2020)
by Aeolun on Tuesday May 25, 2021 @07:01PM
(#27283874)
I see this with basically any Javascript test. Yes, mocking any random import is really cool and powerful, but for fucks sake, can we just use a DI container so that the tests don’t look like satans’ invocation.
Re:It's probably time to stop recommending Clean Code (2020)
by Aeolun on Tuesday May 25, 2021 @06:59PM
(#27283863)
> Make the test red before you make it green, so you know what the errors look like.
Oh! I like this. I never considered this particular reason why making tests fail first might be a good idea.
I don't know which is harder. Explaining this about code, or about tests.
The people with no sense of DevX see nothing wrong with writing tests that fail as:
If you make me read the tests to modify your code, I'm probably going to modify the tests. Once I modify the tests, you have no idea if the new tests still cover all of the same concerns (especially if you wrote tests like the above).Make the test red before you make it green, so you know what the errors look like.