You know what I am talking about... Just think of Gordan Ramsy for example.
Today, I noticed that I am about to have some fatigues myself!
- Don't tell me that working with a version control system takes way too much time making it impossible to meet your deadlines! Just don't!
- Don't tell me that spreading (not adding) your code out over an interface, baseclass and factory takes way much more time! Don't!
- Don't tell me that managers won't give you extra time to write unittests for your project! Don't, Don't, Don't!
"Managers won't give you extra time to write unittests...?"
If you don't get extra time to write unittests it is probably a very good thing! I mean, why do you ask your manager for this in the first place? Are you asking your manager for extra time to have sensible variable names in the code you write? Are you asking for extra time for something "exotic" as comments? Ofcourse you are not! Same goes for (unit)testing! When your manager asked you how long it would take to develop that piece of software he ment "How much time will it take to develop the software in a sensible way!". Asking for extra time for comments or testing or anything else that is normal when it comes to software development is your own attempt to get everybody frustrated... If this would be your attitude I bet that if you would get this mysteriously needed extra time in the first place , your software would still not meet quality standards only to find another excuse... but that's a different story.
"Unittesting takes way too much time?"
The first thing that pops into my mind is what do you compare it to? Changes are that you are comparing a well (unit) tested software system with a hardly tested at all software system. Sure testing takes a fair amount of time but this has nothing to do with unittesting or any other testing methodology.
To make this point extra crystal clear I will give you an example:
Today is your lucky day! Your are asked to extend your Acme-company's intranet with a way too simple news-part.
Your current "timesaving" scenario:
You create the table in your database, write some queries and code to get the data in and out the database, some helper functions probably and finally the User Interfaces. Not using any sensible (unit)testing strategy you probably test the application by inserting, updating and deleting minimal news articles (subject=a, body=a, startdate=select from calendar, department=select from list) as long as it takes for the simple scenario to work. Tired of "testing" you do another test with a large newsarticle. You call it a day and a finished application ready to take into production... only for the nightmare (maybe not your nightmare but definitely mine). When users start using your application bug reports are being made to the helpdesk by phone and by email to be answered, added and forwarded via the bugtrackingsystem only to be discussed with the manager what to do and when. You find the bug, change your code again you do some simple and random testing, do a release (with all the overhead that comes with), close the bug and tell the manager and helpdesk for them to inform the original user.
Why did all these bugs hit you in the face? Because you did not test at all... If this is what you call testing I suggest you buy a book about testing software... I call it a waist of time....
Your new "timesaving" scenario:
Instead of doing those random dataentry scenarios that usually involve endless logins and selecting the needed menu buttons and options... I will write three simple test that do a "way too simple" insert, update and delete. I know that doing those will save me a lot of time compared to your scenario. I will run the tests and modify my code until it works. The time I have left I spent on writing some extra simple tests for my code (test principle: find defects early). Now that everything works I tie things up to my user interface and do some simple but serious Blackbox testing because the user interface contains hardly any code (test principle: software that is easy to test is easy to maintain).
Now when a bug report comes in I check it against my unittests to see why that situation is not covered. If it is covered it's simply a user interface problem easily fixed.
Conclusion:
Unittesting does not take extra time if you don't do extra testing. It does save time because you can just repeat and repeat your tests with one press of a button untill things work.
Of course, even if you would compair proper repetitive manual testing in comparison to proper unitesting, unittesting will saveyou time right from the strart (even before you start refactoring). Not to mention that unittesting not only results in less defects but also leads to better designs....
Happy UnitTesting, Today !
P.S.: I know the example is not UnitTesting by the book its more integration testing but that's not what this article is about...
Posts
5 comments:
Well said. It reminds me of the old analogy
"I've got no time to sharpend the saw. I'm too busy sawing!" :-)
What most people miss out of these is that they usually pay the cost some where...
We don't have time for unit testing. Then something mistakenly makes it into production and the time is spent supporting the product instead.
We don't have time to break out code by interfaces, base classes.....but the time is spent finding, fixing and/or maintaining the same logic duplicated in multiple places.
I do not understand why or how people cannot associate these costs with decisions to cut time during development. I wish I did. Maybe then I could be more convincing as to why we should so something the "right way" up front.
Do you know the difference between Unit tests and Integration tests? I think you made an example of the integration test. I am not sure that big integration tests that tests the whole system with subsystems can be done in terms of bug fixing or development process without additional time involved. Unit tests that covers specific methods and classes can be done without any time expenses with replacing all the sub-systems with mock objects. Sometimes it can even speed the process of bug fixing. I am concerned that integration tests requires additional time to be spent.
I wholeheartedly agree. Unit testing only takes time if it's viewed as an extra activity. Degrading UT, the very best tool to guarantee software quality by thinking it's just some unnecessary and time-consuming bonus activity means the quality is not the priority for the management. Or that they are simply not willing and think that wishing upon a star takes care of that. Optimistic assumptions about quality are fine, but without UT they're just that and nothing more. Or perhaps they think their customers like buggy software and inside every customer is a little sw testing enthusiast. But it's not only managers, imagine how frustrating is to hear the same thing from your colleagues, programmers, who are supposed to "get it". I would say that's even worse. Well, if you can't change how the company works, change the company ;)
Unit testing is not as so much a waste of time rather a time saver when you don't spend time on it.
Yes, we know that is a misconception and we know that unit testing saves us time because we can ensure the quality of the code throughout the project.
On the other hand it takes some time and thinking to create the tests in the first place.
Like any type of testing comes in last in the planning (and also with limited time) there is usually no real time allocated for building unit tests. If the unit tests are on the list of tasks they usually are prioritized well below the functionality tasks and then get moved onwards to the next realease. And then again.
But it's not just the project manager who keeps postponing unit tests. Also developers like building stuff that does something over stuff that just doesn't really do something.
We are still a long way away from Test Driven Development. We say we believe in it, but we do not practice our own believes.
Post a Comment