I do not write tests. Am I stupid?

Question

I've done a little bit of reading on unit testing and TDD, and I've never seriously considered writing tests to such a precise extent. Granted, I am not working on any projects that are ridiculously huge. If all I build are small apps, am I stupid for not writing tests?

Edit: To clarify, when I say "small apps", I mean apps that are not going to control a persons life and/or their belongings. I generally build things that are supposed to make peoples lives easier and to make them more efficient.

Answer 1

It's not about being stupid or smart, it's about ensuring quality and maintainable code. If you don't wish to do this, then don't write tests.

I write tests for everything because 99% of the time an application is going to change and the tests ensure that the application won't break when the changes are made.

Answer 2

Try it and find out. How much of your time now, with your small apps, is spent debugging? How many bugs make it out to users? How good is your design? Are you satisfied with it? Can other developers work on it, understand it?

Try TDD, and see how it works for you. If it helps you come up with happier answers to the above questions, then stick with it.

You're not stupid for not doing TDD - but you might be a little hard-headed if you're not even trying it.

Answer 3

Tests are one way of ensuring quality and maintainable code. Poorly written tests don't help anyone, however, and can often provide a false sense of security that makes bugs harder to pin down.

EDIT:

High quality, maintainable code starts with good design - a project should consider what can go wrong before code is written, and write against that. I'm not saying tests are bad, I'm just saying that you can't say do it all the time, because that's what's 'right' and then think you have it figured out. Just like any other 'rule', it only makes sense if you understand why you're doing it enough to do it well.

Answer 4

What testing do you do? How often do you retest when you make a change? Does the labour of testing reduce the amount of testing you do?

For me, it's more fun to write repeatable tests than do them by hand, again and again.

Overall, the obviously important thing to me is than one tests sufficiently often to catch the bugs.

The unexpected thing for me was that when I began writing explicit unit tests I think my code got better. Just by considering what tests are needed I thought more carefully about the endge cases.

The big trick is to decide where to focus testing effort. UI's? I test those by hand. Gnarly calculation engines - write lots of test cases.

Answer 5

I would at least give it a try. I decided to try it on a side project. Within the first few days I had already saved my hide on several occassions where my code change caused "side effects" that my unit tests caught.

I realized that I was actually taking less time to debug and "test" my code via running it and manually testing it. Now on this project I can change the code and run the unit tests and know it's good instead of running the app and typing in my set of values to test everything visually every single time I make a change.

Answer 6

My personal opinion is that you are sacrificing quality and long-term efficiency by not writing tests. I'm not sure that qualifies as stupidity. By not writing tests for your code you have to rely on other means to ensure correct operation and not breaking your working code when you make changes. The only ways that I can think of to compensate for not writing tests are to be incredibly smart (and observant) so that you never make mistakes (or catch them before they become problems) or to hand test everything in the debugger. I'm not smart/observant enough for the former and don't have enough time for the latter, so I write tests.

Answer 7

The bigger the project, the more important it is to write tests. If it's just you, working on a small project, it's usually a good idea to write tests. If it's you and a team working on a mid- to large-sized project, writing thorough, meaningful tests is necessary if you want to deliver quality, maintainable code.

Answer 8

If nobody will touch again the code, you don't need to write tests for it, since one of the benefits of testing is maintainability (is it right? =P).

And if everything in your work you do is that simple, you really don't even need to matter about TDD or best practices at all. But maybe you should consider changing your job if you want to learn better developing techniques.

In this kind of work, your boss won't accept you taking so long to write tests and coding.

Answer 9

In my experience, the tests are the documentation. If you ever have to explain how something works, you point developers at the tests. Comments are generally not as valuable as the tests.

Answer 10

The big advantage of tests from a programmer's point of view lies not so much in proving that your app works (in fact, unit tests don't really do this), but in allowing you to make drastic changes to the application. With tests, you can change anything/everything and determine that the code does the same thing before and after the change.

Answer 11

I know TDD has received a lot of hype over the last few years, and I understand the skepticism you might have surrounding software projects that get a lot of attention. I can tell you from experience, however, that TDD is not just hype. Before unit testing, I developed a lot of software that I thought was "rock-solid" (no bugs, great performance, etc.). I heard about Unit Testing and decided that I would try it out on a "small project", especially since it would not take along time to implement.

To my amazement, I quickly realized the merit of testing. Functions that I had thought were 100% perfect would output strange results. Changing one component might make another fail its unit test. It was interesting because I realized that my code worked only when I input what I (as the developer) expected a user to input, not what they might actually do in the production version of the app.

This surprise lead me to a number of conclusions about TDD (aside from the typical benefits):

• TDD allows you to test each component at any stage of the application (you can setup the environment for each test). This allows you to ensure a component's functionality remains uniform throughout the application.
• TDD generally encourages good design. You generally can't test individual units of an application without 'componentizing' the system. Breaking the application into testable parts (especially when you use the Inversion of Control Pattern) forces the developer to write better code.
• TDD enhances a Developer's and End-User's confidence in a system. Would you trust a system that was untestable? Or one that is thoroughly tested?

There are many other benefits to TDD. There are also some disadvantages (time to implement, implementing tests improperly). What I can say is that practicing TDD will generally help you improve your development skills.

Lastly, I know you mentioned that your projects tend to be small, so my question to you is why not test? It won't take that long to implement. If you develop in .NET and Java, the major IDE's have features for streamlining the testing process. I'm also willing to bet other languages have similar features in their IDE's.

Answer 12

Kent Beck has asked a similar question in his last blog entry but he states that he only refuses to test things for that he don't know if the will ever be a long term software (maintainability etc.) and the test is very hard to write.

Answer 13

Intelligent people do stupid things all the time. You don't have to use full-blown TDD, but not writing automated tests at all when everyone considers it best practice is certainly stupid behavour.

Personally, I'd say the only justification for not writing tests is when quality matters much less than getting a quick result (not matter how half-assed) or when the code will not stay around long. Throwaway scripts, exploratory prototypes, a new feature with a deadline tomorrow set by an impatient but bug-tolerant customer. That kind of thing.

For everything else, automated tests mean that you will deliver higher quality with less overall work.

Answer 14

Well reading your edits, I'd say your goals are to make people's lives easier, which requires knowing their needs and meeting them. Those evolve, and as they do you need to change your code. TDD really shines in my opinion during those updates... but you have to start with it.

This also helps when other developers look at your code later, and can't figure out how their change broke it, or if they're trying to fix something YOU broke accidentally before you left that place.

Keep in mind, my TDD experience is limited because I have a hard time convincing anyone to start a project using it... but every project that I've ever done that utilized TDD was worlds easier to maintain because of that.

Answer 15

Although one of the major advantages of TDD is that you ensuring the integrity of your code by verifying that it works, it is not the only benifit. The other major advantage of TDD, if done correctly, is that you are isolating a portion of functionality and developing against it. When you write your tests before your code, you are forcing yourself to consider what the exactly your method should do based on the expected result.

When you follow through with this approach from the ground up, you write your tests for your foundation and as you progress further into the application, you'll see points of which you can refractor and refine the code. When you apply those changes, the test itself plays it's vital role and informs you whether you have affected anything else in the application.

Using tests to design software requires a major shift in your process of thinking. Even now, when I fail to do test-first development I have a hard time returning and writing tests. It becomes a tedious task that I'd rather not do. However, when I write them first it becomes a critical process of design. I've found that its much harder to do when entering a project that is on-going though.

Edit: There's nothing like the satisfaction you get when you are writing a method that keeps throwing a red only to have an 'ah-ha' moment and watch that bubble turn green or the feeling of relief you get when you make a small change that you don't think will have any affect on the rest of your application only to see red lights go off.

Answer 16

As I mentioned in another discussion, I was an advocate of TDD until I actually tried it on a real life project - not any more.

However, I do find automated tests to be very useful, esp. acceptance tests, integration tests and regression tests. Just don't think the development process should be centered around tests. Also, I did not see much benefit from unit-tests - maybe because I am mostly using statically typed languages.

Answer 17

Not all code can be unit tested and it doesn't suit every situation. So pick something non-interface driven as a starter, such as something financial or calculation based. Try it and you may grow to love it.