Comment by hinkley
5 years ago
> The best code is code you don't have to read because of well named functional boundaries.
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:
Expected undefined to be "foo"
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.
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.
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.
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.
> 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.