About Anirudh Bhatnagar

Anirudh is a Java programmer with extensive experience in building Java/J2EE applications. He has always been fascinated by the new technologies and emerging trends in software development. He has been involved in propagating these changes and new technologies in his projects. He is an avid blogger and agile enthusiast who believes in writing clean and well tested code.

10 Reasons why you should NOT write unit test cases!

Finaly, here is a blog in support of all those who feel writing unit test cases is a sheer waste of time.. or is it?? Lets see..

Below are few of the reasons:
 
 
 
 
 
 
 

  1. You are Neo (from The Matrix) , the ‘chosen one’

    You can see the code getting executed as green binaries. You feel the code and understand every use case, you are just so rediculously genious that you don’t require any safety net of unit test cases to identify problems; you can see them with your naked eyes!

  2. Your BA / Product Owner is 10th avatar of Lord Krishna

    So whatever he tells you is just Absolute truth! There is no confusion, discussion, ambiguity in the stories because those are the words of God! How can you not understand or even question the divine words? Why do you need stupid unit test cases to identify missing use cases, when nothing is missing!

  3. Your team has mastered the ancient art of predicting future.

    You have the Oracle in your team, you have forseen all the changes which are going to come in future. You have peeped inside your constumer’s mind !

    When you have already taken care of all the changes before hand, then why would your code change ever??

    Why would there be any refactoring??

    Why would there be any enhancement requests?

    You have written the perfect code for present as well as for future, so why should you waste time on writing unit test cases?

    Why would you be bothered to know about the impact your change might have on the other modules?

  4. You know that your project will never get into maintenance phase.

    Can you tell me how your code would never go into maintenance phase?? Any guesses??

    Yeah right, it should never get released..!! You should just continue coding for 2 years without following any principles of agile or testing!

    I’m pretty sure that; as a result this project will never go live. Problem solved. No live code.. no maintaince.., no refactoring.. no bug fixing.. no changes.. easy peasy..

    (and if it goes live somehow, switch the company )

  5. You are an evil consulting company who makes profit only by maintenance of projects!

    Your company has bid for a project with insane timelines and cheap billing rates. They know very well that its an investment to deliver project in almost no profit because the return is gonna come soon!

    How?

    They know, what will be produced is gonna be crap! And of course it will have no unit test cases at all!

    Result : The project will surely be delivered, but to fix its bugs/maintain it, it would take 10 times the effort than what it took to build it! And since you have built it real bad; only you know how to fix it!

    And as there are no unit test cases, no one would be able to analyse what would go worng when you change one moving part! Better!! Why? Because then you would have introduced more bugs while fixing the older ones!!! Result ; more billing!!

    (muwhahahaa..haahaaa … evil laughter!!)

  6. You know you are not going to be around

    You will not be there for long in the project or company to see if the project failed. Best use case : You are serving your notice period! You know you are never going to see the code which you are writing today, its not your responsibility if things go wrong later!

    (Make sure you change your email address and phone number after you switch the company, and have taken relieving letter  )

  7. Revenge is best served cold!

    You have suffered all your life as a programmer trying to fix bugs in legacy code which had no or very minimal unit tests. Half of your life got wasted in identifying what’s happening and the other half trying to fix the mess which your change created!!

    You have had it enough!! Now its time for other earthly creatures to suffer in hell the same way you did!! So you don’t write any unit test cases, let the person who will be working on your code later understand your pain and misery!!

    And, finally you will be avenged!

8th , 9th and 10th reason, I leave for you guys to figure out, I’m sure you must have hundreds of more excuses not to write Unit Test cases.

In case you dont have these reasons then better start writing Unit Test cases now!!

PS: I wrote 10 reasons just because it sounded cool

Cheers…
 

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

10 Responses to "10 Reasons why you should NOT write unit test cases!"

  1. Christian says:

    You are chuck norris, you can roundhouse kick all the bugs away.

  2. allanc says:

    Hahah, good one. I saw the topic and rushed over to set the record straight.

    You should add some “real excuses” developers give and debunk them next.

  3. Jose Maria says:

    7 Reason is ny case hehe.

  4. Chuck says:

    Loved it! Since I don’t meet any of your criteria for *not* writing tests, I guess I’d better get started on writing them.

  5. Jaker says:

    javacode geeks remove the popup newsletter on scrolling to the bottom. Better put a widget for it. We are not blind that we need a popup.

  6. Lukas Eder says:

    Man. You tricked me by 3 reasons. I would’ve never read a “Top 7″ article!!

  7. Rachid says:

    Sorry your article has nothing to do with software development. How can you be sur that your program works as expected.? How can you verify that your program works correctly after last bug fixing period.?

Leave a Reply


3 − one =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books