This will be an estimate answer, because if you are interested in automatic tests, write automatic tests…
Richard Koellner writes about Trace editions in the code.That’s where I feel a little caught, because that’s how I develop – and I typically remove them.
Automatic tests have both advantages and disadvantages, depending on how a project is created.In software technology, one learns to plan projects in detail, a project goes through individual phases of development, the algorithms are planned, the user guidance, case analyses. This includes testing during development, for example through test-driven development and after development for quality assurance.
A beautiful plan that I have never seen before in reality.
The reality is often that features are knocked out.There is no time for error queries or even for tests. You have an existing product and then something is bent in, because a function is needed at the customer’s house or functions are absolutely still needed until the next release.
When Richard Koellner writes about “old-serving ones”, I would like to counter that younger colleagues in particular are more likely to be put under pressure to find solutions quickly, i.e. to completely renounce the rules of art, because the manager is now looking for features. Requires.The “old-serving” are also a little more relaxed.
If an exception ends up in an empty catch block (or tendentiell all) and thus the error handling is successfully completed, this leads to interesting effects.
Therefore, I would like to refer the question “Why do many software developers do not write automatic tests?” primarily to the company culture.Is the company more interested in delivering features or implementing reliable software?
The question often arises when choosing the programming language.Dynamically typed languages also have a much more dynamic handling of errors. In this respect, therefore, there is already a willingness to accept emerging problems in the first decision in principle. The consequence of the election would then have to be an extremely increased number of tests. Now, dynamic languages are often chosen with the ulterior motive of increased expressivity, and therefore conclude saline to increased productivity. Of course, this is absurd if you have to write tons of tests afterwards.
Currently, the more restrictive the language, the more source code to navigate around the restrictions.The more restrictive the language, the less I can test. A restrictive language does not allow many semantic errors in the first place, accordingly one does not have to and cannot test whether a logic error has arisen, because one cannot formulate it in the language at all.
The more restrictive a language is used, the fewer tests are required.And here you occasionally hear that the semantic errors disappear and the developers then do not test, because if the customer is not satisfied, he reports well. In individual development, the customer is often also accompanied by the development process and constantly introduces changes. On the one hand, it is actively testing, on the other hand, the changes mean that automated tests also have to be continuously adapted. So here they are hindering.
In fact, in the time I develop semi- or professionally, I have never seen a working, planned software.
Thus, a different development culture exists in every software project.Test-driven development makes sense, but is inflexible. Very agile software development, on the other hand, is difficult to test statically. And in the end, no matter how you do it, tests cost money. Tests also save money. Finding the right mix is a tightrope walk for every project.
Tests take time.Development time is also an interesting requirement that influences the development culture: In a start-up situation, you have a manageable product in which everyone still knows every function personally and you need a product that can be sold quickly. There is no time for quality assurance. Quality is needed when you can lose so many customers that losing them can be dangerous for the company. Or a design flaw will result in massive changes in the software. In the meantime, as described, the start-up and the traditional company are often patched up as soon as the customer wants improvements. But not everyone knows code anymore, more often colleagues spark with their adjustments in between, because they no longer have the complete overview of a source code.
As the company grows, it’s also more time to hire young developers to test existing software and stabilize the code base against unintended changes.
Testing is, in my opinion, primarily a corporate culture rather than a matter of the mentality of professional developers.
The developers who don’t care if their code works in the end are there too – but that’s rare.