Automated testing is slowing me down.
That's probably caused some heads to explode already but let me explain further.
I'm not talking about end to end UI automated testing or complex performance testing, I'm talking about simple unit testing. I've come across this a lot but actually hadn't realised how deep the mis-understanding gets until some of my team members were showing signs that they actually don't care about build errors either.
The project in question is Typescript, NextJS and React. To explain further our pipeline would fail if there's a build error, hence preventing deployment, but we can skip the build prior to pushing by a certain flag on the git commit line. We do have husky pre-commit hooks setup that would build and run tests prior to a push.
Then there were increasing incidents of the pipeline failing due to people not wanting to run the husky pre-commit hook.
This is all solvable by git pulling the branch, and sorting out the error, then pushing again. But this post is about developers perceptions of tools that would ultimately help them wrangle the sea of errors that might occur when building an application.
To the point now I recognised some developers thought that a project build is getting in the way of them showing that they have done their ticket.
At this point you maybe thinking this is ludicrous, of course you need to compile and build before the app can be used. However I remind you that JavaScript is an interpreted language and before TypeScript or WebPack we "Web" developers just used to /ship/ code.
So the next time you hear "I don't have time for unit testing" remember that some developers don't even have time to ensure that the code builds properly.
Top comments (0)