May All Be Properly Tested Ever? | TestFort

May All Be Properly Tested Ever?

You are here

May tests harm?

man-in-trenchcoat-with-magnifying-glassThere are many developers that believe they have just found the best way to develop ever and everybody is to use it and the more they test the better. Things like Behavioral Driven Testing do seem like a silver bullet to them. It’s as if a cure from cancer has been found. Mysteriously this phenomenon has made its way to the minds of many experienced developers and testers.

But let us face some facts. Just  consider the total amount of testing tools released every day. All of them are offering new functionality. Regardless to say there are new methods of testing and development that are raining on our heads from Agile and Scrum with their three-lettered techniques like TDD, BDD, BDT, etc. to the almost forgotten Waterfall. Would mankind really bother to find a solution to an issue that is already resolved? If things were OK with software quality assurance would developers still put as much effort in coming up with something new in this field?

Don’t get this wrong. There is nothing bad with ‘testing early and testing often’. There is nothing wrong about automation as all that has colossal value in today’s software. But there is always a thing like ‘simply too much’ to keep in mind. No project, although many tend to, may allow itself to be under test for the total 100% of time.

In fact, some testing activities may not be considered as much more than wasting time when others may even harm your project. Just imagine the emotions any good developer will be experiencing while refactoring any particular test suit in which all but the object under test was mocked in order of decoupling implementation code from the test.

Where and when is testing before coding and automation are a good thing?

  • Regression testing. Always. Well, preparations to regression would be more precise in this context. When there is still not too many code written it’s quite easier to place in inside unit tests and to thank yourself later on.
  • Protection against harmful changes. If you are in a project with many developers (and each one of those often has his own touch with coding) or a very long and deep project that will have layers of code one on another you won’t survive without automation.
  • Well written tests always have more to say than implementation code. No matter which framework you will be using whether it’s Cucumber or something less shiny. Requirements are to tell how software should work.