Common Excuses Why Developers Don’t Test Their Software

创业投资 2017-10-01 阅读原文

Excuses for Not Testing Software — The Experts Guide (ISBN 6c6d66616f)

I have never met a single programmer who can code perfectly. I don’t think such a person exists.

Once upon a time I hated testing software. It wasn’t important to me. I didn’t see the purpose. It seemed like a huge waste of everybody’s time and money.

Throughout my career I was never taught how, or why, I should be testing my software. I made lots of excuses for not wanting to learn. I spoke to many developers who also made excuses for not wanting to learn. They still make the same excuses today. I eventually learned, they didn’t.

Throughout my time working with others I’ve came across many different opposing views to software testing (some were valid, but that’s another blog post). Below are some of the most common reasons developers don’t give software testing a chance …

My Code Runs Perfectly. Why Do I Need To Test?

I have never met a single programmer who can code perfectly. I don’t think such a person exists.

Take for example the biggest tech companies in the world. Google, Facebook, Rockstar, Sony etc. They hire the smartest developers in the world. Yet, their developers still manage to write insecure code. The proof is in the pudding folks:

(FWIW any web developer who leaves an XSS or SQLi vulnerability in production code needs a kick up the backside!)

My response to those who proclaim their code is perfect: How do you know your code runs perfectly. Have you tested it? Can you test it now and tell me it runs perfectly?

But, I Don’t Know What To Test?!

Test all the things! — with the exception of 3rd party code which should already come with its own tests.

I’m going to take a quote from this StackExchange answer , because it makes sense:

1. Test the common case of everything you can. This will tell you when that code breaks after you make some change (which is, in my opinion, the single greatest benefit of automated unit testing).

2. Test the edge cases of a few unusually complex code that you think will probably have errors.

3. Whenever you find a bug, write a test case to cover it before fixing it

4. Add edge-case tests to less critical code whenever someone has time to kill.

It’s difficult to know where to start when you’re new to the world of software testing. There’s many different types of software testing. I always recommend beginners start with Unit Testing , Integration Testing and Regression Testing .

There’s a whole heap of software testing methodologies. Some you will never need to perform if you’re working in a team, but it’s useful to at least know the difference between them all:

  • Acceptance testing
  • Alpha testing
  • Beta testing
  • Black box testing
  • Comparison testing
  • Compatibility testing
  • End-to-end testing
  • Functional testing
  • Incremental integration testing
  • Install/uninstall testing
  • Integration testing
  • Load testing
  • Performance testing
  • Recovery testing
  • Regression testing
  • Sanity testing
  • Security testing
  • Stress testing
  • System testing
  • Unit testing
  • Usability testing
  • White box testing

If you’d like to know more about all the different types of software testing you should check out this article .

The important thing is to make testing a necessity and not an option.

Testing Is Difficult and Confusing

Anything is difficult if you don’t know how to do it. It takes time, practice, experience and patience. Chill out, relax, and have fun when learning. Expect initial failure and confusion. You’re only human!

Once you learn how to test and start to feel comfortable doing so you will find it’s actually pretty simple!

Grab a good book. Read documentation. Discuss with other developers on IRC/Slack/Discord etc.

Testing Increases Development Time 🙁

This is a common misconception related to the last excuse.

Anyone new to testing will struggle initially. New lands are being explored. It feels uncomfortable. You’re human, and it’s perfectly normal.

In the early stages it will cost lots of time. Stick with it, keep learning, and eventually it will become second nature. The trick is to make it a part of your software development workflow so it becomes habit.

Writing tests saves lots of time and lots of headaches in the long run. Being able to repeat tests at the click of a button and confirm everything works as expected gives you the confidence to ship software into production. If anything should go wrong you can simply run your tests to help discover the source of the bug.

There’s a sense of fulfilment when you ship code that passes every test. Maintaining testable code is always easier, and more pleasurable, then working on a system without repeatable tests.

Recommended Reads

If you’re new to software testing, or want to learn more, I highly recommend the following books. I’ve hand picked these from my personally library. They are fantastic!

Happy Testing :grinning:

Hacker Noon

责编内容by:Hacker Noon阅读原文】。感谢您的支持!


From 1 to N: Distributed Data Processing with Airf... From 1 to N: Distributed Data Processing with Airflow Betterment has built a ...
Testing the equality of coefficients – Same Indepe... As promised earlier, here is one example of testing coefficient equalities i...
腾讯面试官送给准程序员的一些建议!... 近期面了 30 多位工作 2-10 年不等的技术骨干、总监、CTO,对于互联网或计算机方向的同学们的一些建议,都写下来了。 1. 趁着在...
Table driven tests in Go In practice-go we often use table driven testing to be able to test all...
BLeak: automatically debugging memory leaks in web... BLeak: Automatically debugging memory leaks in web applications Vilk & Berge...