Do you have unit testing in your projects?

Question

I know unit testing is important - everbody knows that. But in most projects that I see there is almost no unit testing (except open source frameworks), but a lot of human acceptance testing.

What's your experience?

Answer 1

I use MSTest unit tests for my lowest-level functions; I need to add more, however, for higher-level components. Later this week I'm planning on modifying my build script to automatically run all unit tests after a build.

Answer 2

In the projects I've worked on it's varied widely, from strict unit testing on every aspect to virtually no tests and all humans poking at it. I think it really depends on the manager, the project lead and the overall purpose of the application.

Answer 3

I work in a small time pretty unstructured company with only a few developers. I unit-test `my´ classes, which saves me time and gives me confidence that they do what they're supposed to.

Answer 4

I demand it. I don't require complete code coverage (I trust that your getters and setters work properly, and that dialogs pop up when you click a button), but for tricky algorithmic work it's absolutely essential.

Answer 5

I've never worked in a place that had unit testing in place (and have worked for several different places). I'm interested, but don't even know how to start to implement it.

Answer 6

I don't really like unit testing. I find it doesn't cover the kinds of bugs that the software I write is likely to have. That said, I do use unit testing for more complex algorithmic stuff. Most of the time, I just go on a mission to try and make my software break, though.

Answer 7

We've had to write a chess-playing program as part of Algorithm Design class. Instead of focusing on algorithms (minimax is just copy-paste material), we tried to work as a team and followed what we'd been reading online.

One of the feats I really liked was that for each module we wrote (rudimentary, I presume) unit tests. Because time was short, we didn't get to unify them into a pre-commit hook, but we had that in mind, too. So, yeah, next big project I'm trying is going to have at least basic unit tests.

Answer 8

The main body of our application code was written 12 years ago, so there is no test suite for most of the code. We've recently been trying to retrofit some automated testing into a few of the classes, but it's pretty hard.

I won't speak ill of those engineers, because they were doing the best they knew how (keep in mind that the GoF book was published in 1995), but either by design or organic growth many of the core classes are so tightly coupled that it would take a monumental refactoring effort to make them unit-testable. A good example of this: the core USB communication system relies on diamond inheritance. I'm not kidding.

So we add unit tests when we add new classes to the system, but we have less than 5% coverage.

Answer 9

Yes. It wasn't easy to start, honestly. But, the benefits have been tremendous.

It is good knowing that things "still work" as I originally intended them to. When the tests fail... well, I can ask myself the question "Why?" and determine if I've screwed something up via a code change or if the requirements have changed and made the test and the original "rules" enforced by the test invalid.

Sometimes the test needs to change because the original assumptions are no longer correct. Without these tests holding me accountable (or holding the classes they test accountable), I have no way to know that everything works... I'm guessing at that point.

Answer 10

I would rate integration testing, done by humans on the system as a whole, at about 10 times more important than automated unit tests. If the application meets the requirements and doesn't break when people are actually using it, you're done.

The opposite is not true. Automated tests can all pass with flying colors and the application as a whole can still fall on its face.

Most of us are writing very few discrete componentized algorithmic functions, which are the true place for automated unit tests. But many of us are trying to shoehorn our data processing, business logic and UI rendering into this model out of an understable, but misplaced, desire to adhere to best practices.

Answer 11

We practice continuous integration and have at least a test for every single class. This is the only way you can confidently refactor your code and be sure, no matter how small your project is now, it will grow and you will loose track. So, put tests in place as soon as possible.

Answer 12

There was none when I joined here and there are still very few. My boss isn't overly keen on them - they seem to mean code takes longer. However I tried to explain that to create the tests I need to refactor the code and write the tests. His response was not to write the tests and then I wouldn't need to refactor and I can get on with fixing the code.

Answer 13

yes, although some of the projects I've worked on recently have had more "integration" tests than unit tests (which is almost as bad as no tests as I've experienced it), but my current project has reached about 95% code coverage. It's a Java web app, we're doing test-first using:

• Junit (3)
• Jmock
• and some BDD practices

Answer 14

Yes, we now have some of our components that have unit-tests. I mean, true unit-tests a la XP, that is, automatic. They are mostly validating the most recent feature we added to our legacy code base. We do not write unit tests for the sake of adding unit tests, we add them when we have to modifying legacy code.

A good rule of thumb is to create a new test every single time you fix a problem. This test will give a evidence the problem is fixed and prevent regressions.

They are run automatically by a continuous integration server.

For the legacy functionalities it is far simpler to implement automatic (that's the key word here) end-to-end tests. YMMV

Answer 15

If you write automated tests to do the same thing that your manual tests are doing, then you can begin to realize gains. This is hard to do in legacy applications, but with a little concern for decoupling your code, and observing the single responsibility principle, your code base can be made to be more testable.

The notion that algorithims are the only places you can unit test is a fallacy. If your code does something, it can be tested.

Answer 16

I've only worked for one company which used unit testing consistently, and that's the one that I run. I do fairly heavy automated tests for all back-end code (i.e., anything which only talks to other code, not the user), but do still rely on human acceptance testing for the user interface. My clients will occasionally question the time I spend writing test suites, but it's easy to convince them that it's time well-spent when, e.g., they decide that they want to support multiple email addresses per user instead of just one and I'm able to locate every problem caused by this change within a matter of seconds (and then verify just as quickly that all of them have been resolved after I'm done).

Everywhere else, though, where it's been run by managers rather than developers... Yeah. Not a unit test in sight, beyond the ad hoc stuff put in place to identify whatever's being debugged at the moment.

Answer 17

I work for a company that has products containing hardware, firmware, and/or software. Integration testing is paramount; unit testing is, well, less formalized. If programming is not considered a "core competency" of the company, I think it can be harder to include some of these practices.

Answer 18

Of course. I actually believe in test based development. You develop a spec for a particular class, write the test code to use and test that class, then code to pass the tests. Though that doesn't always fit into a particular project/company's development processes. But unit testing, in my opinion, is one of the most important things you can do to provide a quality code base.

Answer 19

Anytime the complexity gets a little high I unit test.

Answer 20

This is a useful overview for anyone unsure about the whole concept, or indeed anyone who is familiar with it.

There is no unit testing policy at work, but I try to write unit-ish tests whenever I am write more traditional data structure type modules of code because it's a very useful way of interrogating you own mind in order to make sure you actually know what you expect of your own code.

Answer 21

My current project has unit tests, but unfortunately most of them were written by me while the other developers feel that it gets in the way of actually getting their code written. Which I believe is wrong, they just haven't taken the time to learn how to develop using unit tests properly yet. So we have pretty spotty coverage.

Human acceptance testing is irreplaceable, but you have to consider the productivity of their time. Developers have a responsibility to assure some level of quality on the code they have given to any human to test.

Answer 22

Yes, where it appropriate I'll write tests, Unit testing tools such as TestDriven.NET makes it brain-dead easy, although I am by no means "Test Driven".

I used to write throwaway console projects to get a method or class started and then moved it across to the main project. Now instead I flesh a class out with tests in the project itself. TD.NET also has a neat feature where any method can be executed independently from the rest of your code the same as a test. So where previously I might have used something like Snippet Compiler to try something out, I can just do it in the current module I'm working on.

Answer 23

We have over 90% unit test coverage on our current project. This gives us the confidence to be able to do re-factorings that will have less likelihood of introducing bugs.

Functional testing of requirements is more important than unit testing, but unit testing helps you achieve better functional testing.

Testing is the only way that you can know for sure that your development efforts meet the requirements. Testing should include unit testing and functional tests created by the developers, testing done by a test team, and user testing. Don't forget load / stress testing. Many concurrency bugs will never show up until the application is under load.

Any time a bug is found via a test that is not already automated, it should be added to an automated suite so that regression tests can show that newly added functionality does not break existing functionality.

Answer 24

A good example for unit tests is CPAN and those buildbots that test new modules on various systems.

We use test-driven-development at work, for my own project I don't see any sense in writing tests. When I don't think of a problem while writing code - why should I while writing unit tests? ;)

Btw: Does anybody use unit tests in C with e.g. Check?

Answer 25

We have both unit and integration tests (using dbUnit in Java). In a recent, massive migration from an OODB to Postgres/Hibernate, they have been invaluable. There is no way we could have done it without them.

In fact, as bug reports come in, I would estimate that 90% of the bugs found did not have tests around them. If it was tested, then it is generally 'good'.

"Checking in code without unit tests is like betting on a poker hand without looking at the cards" -- Anon

Answer 26

Once again I got handed down a code base that has no unit testing (and no structure to speak of). I attempt to create test as I muddle through the legacy code when doing upgrades and bug fixes and while refactoring. I've got a lot of good ideas from the book Refactoring in Large Software Projects by Lippert and Roock for making the old code testable.

I've grown to love unit test when dealing with projects that are new to me. Well implemented test give me a huge boost of confidence to get my hands dirty with the code and actually understand it better. Especially when none of the original developers are hanging around explaining their choices and intents.

Answer 27

At my current employer, most developers are just learning .NET, moving from FoxPro and/or VB6. We're slowly introducing unit testing, but are finding that more general OO principles and designs need to be introduced first to help people learn how to build testable code.

Unit tests on a dependency ridden code-base are not only hard to code, but too fragile to stand up and create a bad impression of tests.

Answer 28

Yes, and I build it into the Ant file so that it has to pass the unit tests before it can be deployed. Also, I use Cobertura to check for code coverage of the unit tests.

Answer 29

If it's a small enough project and you're a good enough developer you really don't need to be unit testing your code or doing more than a cursory inspection of the functionality of the program. That being said, those are small projects and in larger ones unit testing is a life saver.

It's all about give and take I suppose.

Answer 30

The problem with human tests is that they're not consistant. A human being can be bored of doing the same tests again and again. Sometimes, humans are taking short cuts, assuming that some previous tests should not be redone since the modifications are not supposed to affect some parts of the application.

Automated tests should be able to be redone anytime with the widest scope possible. If any problem should occurs in the application that the automated tests did not detect, they can be augmented to include missing cases. In the long run, the become more and more trustable.

Answer 31

My experience is that unit tests are pretty common.

The main project I work on (Bazaar) has a large unit test suite — but that project is open source, so perhaps that's not surprising to you!

I've also worked on Twisted (open source), and Launchpad (currently closed source). Both have unit tests.

I have worked on projects without unit tests, but that was quite a few years ago now, and I think those projects suffered as a result.

Answer 32

I'm currently working for a company that has some projects with unit tests and some without them.

In the last project I've worked on, we used TDD. It was my first time writing tests before the "real" code, and it was hard, it was new for me at code level, and also at thinking level.

In my current project (legacy code, with some new features), there were very few tests (almost all ignored or not running in CI). I insisted over and over to write unit tests and finally we're getting started =).y

Automatic unit tests are very good for a lot of reasons that you can read in books and the Internet. It's hard to start, but you just have to =).

Answer 33

Unit testing can't work when you are building the application from scratch, because you'll be focused on making it work, not breaking it, at first.

However, real-life situation for making unit test invaluable is refactoring. When application or part of it gets to the running condition, and users' not complaining are real proof of it, then you can say that behaviour of the system components is as it should be.

And then, you want to make some architectural changes, for various reasons, for example lifting some parts of code to meta-level, due to performance issues, due to obsolence of some library or part there of... You'll want to fix some part of existing behaviour as ''in stone'' and make unit tests for it, then refactor.

Answer 34

I've always worked on legacy code which had no unit tests. I've produced few unit tests. The employer does not want to pay for unit testing or "we'll do that when we have time". There's never any time to develop them later.