Why Swift Programmers Don’t Test Their Code
10 all-time classics we can all relate to
We can all relate to these reasons why code gets committed, or (worse) goes into production untested and perhaps not functioning correctly.
These aren’t necessarily excuses, some are actually reasons. That doesn’t make them good reasons and we need to look carefully why programmers aren’t testing their code, and what can be done about it.
“It works on my machine”
We’ve all done it. We might even run through some Unit Tests on our machine before pushing the code and expecting it to work.
One type of programmer will insist that the problem can’t be with their code, and seem to believe that their code is an extension of their self and will defend their work at all costs.
The result of this can be code being delivered to users that doesn’t work. They use the wrong device or use the code in the wrong way. The fault simply can’t be with the programmer or the code, since it works on their machine / works for this use case / conforms to the requirements (delete as necessary).
This is despite the fact that testing on your own machine isn’t enough. If you are deploying to any number of devices (above 1) the configuration won’t be the same.
