Tag Archives: testing

rushing without automated tests is a business mistake

excerpts from article by Joseph Puopolo, An impassioned plea to other Start-up founders to use automated tests.

Working on the business side of the shop, I have fought against automated tests for a while. That all changed recently
….

The conclusion I reached was that automated tests save developers time and let you deliver more. This was a painful admission, but a correct one.
….

I have been in multiple start-ups where automated tests didn’t exist, and let me just say the QA overhead was astronomical.
….

While it seems counter-intuitive, building tests saves you time in the long run. The knee jerk reaction is to spend your time building new features. I have had this reaction many times
….

One of the biggest time sinks in development is finding the problem. With proper tests in place you can isolate and figure out where the issue is.
….

With automated tests in place, it is easier for new developers coming into the system to understand code that they didn’t write.
….

automated tests save time and help you get to market faster. If your goal is to rush to MVP without putting in place a scalable infrastructure that allows you to grow your code base, you are not only making a technical mistake but a business mistake.

a test of knowledge

Leave a reply

by Kevlin Henney

www.artima.com/weblogs/viewpost.jsp?thread=340839

(my emphasis)

Summary
What can you learn from testing? When you look beyond the red and the green, the fail and the pass, you can learn a lot more about the nature of the code and the nature of the problem domain. And there is a lot to learn — software development is called knowledge work for a reason.

….
deeper truth becomes visible: knowledge work is about knowledge. It’s about knowing stuff and, most often, also about how you deal with stuff you don’t know.

….
curiosity is key to how we address a lack of knowledge. Questions are the agents of curiosity. Even without answers, questions can help us to increase and refine our knowledge, to learn.

….
Software testing is a form of learning. …. A test allows us to move from belief to knowledge

….
the first part of any feedback-based process is generating the feedback; what you do with it becomes the next challenge

….
learning opportunities are available from … the formulation [of testing] rather than the execution of tests.

….
The reality is that some things just are harder to code and test no matter how you write the code or the tests. When complexity was being handed out, not all applications and domains of interest were created equal.

on accidental complexity:

in principle, avoidable. This is the realm of technical debt, baroque frameworks and rococo architectures. It’s where speculative generality has come home to roost, copy-and-paste code has blossomed and coupling has weighed anchor. This is where the observation “if your code is difficult to test, it means your code is messy” may often apply.

agile testing: who i listen to