Nasa apparently split programming teams into two halves - one half does the development and the other half writes tests to make sure the code works. (Although these sound more like functional tests than unit tests). The cunning bit is that every few months the two teams swap places.
It sounds like it would work really well for software that needs to be very robust, although I’m not sure most regular studios would be willing to pay for it.
Firstly I should say I’m doing a lot of lua code at work recently, and while it’s nice language it’s an absolute pain to refactor reliably without introducing more bugs. After every change you’re never really sure if you’ve not made some silly typo or mixed your object types up and it feels like walking on egg shells the entire time. Unit tests would make developing with it much, much nicer. There’s be extra code to maintain, but it’d easily save time over tracking down the latest stupid bug introduced.
Currently we seem to be doing the opposite - it’s hard to refactor so we don’t. This obviously means the code gets harder to actually get stuff done in.
So I think in certain situations unit tests can be a huge win. For something like a Rails webapp where you can unit test the bottom 80% and ignore the ui side it’d be great.
But for statically typed languages where most of the interesting stuff is in the ui (ie. java games) I’m still undecided.
That sounds unit tests patching the TOTALLY AWFUL LANGUAGE.
Wrt NASA - there, precisely double the development time. Probably not that many actual bugs caught, but then, when a bug causes a billion dollars of space shuttle to fly into the Atlantic, you’d want to be quite careful 
Cas
Hopefully the learned something from that whole O-ring thing. Patriot missile misses target by a bagillion miles? Programmer didn’t understand that 1/10 of second isn’t representable in floats. Euro rocket goes boom. Programmer doesn’t understand truncation to 16-bit integer. Design. Data-structures. Algorithms. Numerical Analysis. (Oh, and listen to people with experience in the field in question.)
Scala can be used to solve mundane problems in mind-bendingly elegant ways.
Lots of programmers are stuck in jobs with really old code and technology for business reasons. I feel for them. Scala is bleeding edge, which is what most programmers want.
It sounds like you are weary of programming. I question whether games would reinvigorate an interest in programming, because at the end, games are still programming. Why not consider a field with more of a purpose that you believe in?
(totally off the unit testing subject, but on a subject that’s more interesting to me)
For me unit tests may be considered as an insurance.
You pay for it (time it cost), but you will probably never or rarely need for it (bugs that it may detect and safe you).
And like insurance, in some use case you can avoid it, and in some others, you just simply can’t.
By example, when i search a library like new collections implementations or distributed cache, i start to check if they have a good javadoc and if they have a good unit tests that covers the API.
I mean unit tests by the fact to test a “short” perimeter of classes event if it’s a functionnal tests.
I personally use unit tests in these cases
while coding some new non-trivial functionality, before plugin it into the rest of the app structure, so that when the plug fails (it will), at least I know the new subsytem works, it’s the plumbing that’s wrong
to cut down development time of that new functionality, coz’ it’s very fast to launch the tests. I don’t have to launch the whole app and put it into some specific state, just to make some tiny tweaks.
But after that, I hardly need the tests anymore.
They even become a pain when doing heavy refactoring of public interfaces, coz’ the tests need to be fixed too.
These talks on unit tests and good practices by Misko Every are really nice, because he explains the whys
I don’t see how the unit tests even managed to find 3 bugs. The point of unit tests is to prevent bugs. If there was a bug in the codebase, then the original unit test failed to prevent it, and it was only found by dumb luck when someone wrote a new unit test for some unrelated functionality.
In my work, we follow test-driven development. My code is all to do with parsers, code generators, metamodels and validators… I would be unable to function without comprehensive test cases verifying intended functionality and catching regressions.
The more business logic you have, the more you’ll benefit from having automated tests. Not at the time of writing (although I use them to good effect to dev-test my stuff), but at the time that changes need to be applied. That’s how I would summarize it anyway.
It’s the regressions that it helps catch that is the redeeming feature. That said, we have people who just go and change the test instead of making the code work properly :
Endolf
Unit tests are another way of defining requirements and an automated way of validating them. Just like requirements they fall into the same problem - human engineers define them.
As to not being able to function without them, of course you can. You just have to drive your development from your requirements manually and validate regularly by hand. It’s not as easy and relies on you being conscientious and capable/qualified to do your job something thats severely lacking in the industry today. The danger with unit tests is that you end up relying on one person’s interpretation of the requirements (or maybe more, one person at one time in project lifecycle). Revalidating requirements understanding regularly used to be implicit, now with unit tests it doesn’t happen so much.
Cheers,
Kev
Unit tests are certainly not a magic bullet, but they are one tool in the process. On a large system that has had many people work on it, leave, and new people come in it is a very valuable one. For small systems or small teams it probably doesn’t make as much difference.
Endolf
Depends on the project. For Kryo’s serialization, without unit tests I would certainly break things left and right, without realizing it. I’m sure other projects are similarly sensitive to changes.
Writing a proper test case is a problem in and of itself. When first writing the tests against a class, a programmer tends to write test cases that will obviously pass, because they only handle the cases they had in mind when implementing the class. This still helps prevent future maintenance from breaking the class’s established behavior, but hardly proves the class is bug-free (or meets the specifications under a design-by-contract model). Splitting up the team (NASA-style) makes logical sense, but doesn’t sound practical for most projects.
Personally, I’m in Cas’s camp: I’m the only one working on my code right now. Stack traces tell me where the code breaks. Inserting System.err.println’s helps me debug the problem. I don’t even use an IDE debugger (but sometimes use VisualVM to inspect state at runtime). I also agree with Roquen’s comment on (not) treating computer scientists as code monkeys.
I’ve never been on a design-by-contract project. In such an environment, are unit tests entirely redundant/unnecessary, or can unit tests still be constructed per the contract (by Team A), then run against the code being developed (by Team B)?
Although I am a firm believer in unit tests, I do find they are hard to implement for human-oriented code. I’ve been on projects that tried to unit test Swing user interfaces and that was both painful and unproductive. Testing the underlying data model with unit tests was no problem of course - but testing that widget X was present and clickable on screen Y was nearly impossible. Likewise I have 96% coverage of my metamodel code (it’s dropped from 99%) but for my PDF generating code I have zero test cases. I have yet to write a test for my OpenGL code - how can you write an automated test that pixel x has been fogged correctly from all perspectives, for example. Correct me if I’m wrong, but unit testing the user interface is pretty much impossible.
But for the backend, unit test are invaluable and indispensable.
By the way, I don’t agree with the “I don’t need unit tests because I just follow the stacktrace” camp: most of my bugs (and I certainly make enough) are in logic or behavior. Unit tests let me check the logic and also fire the exceptions in my code - otherwise you can go to production with your exception cases mot covered by manual testing.
Clarification of my stance above: I don’t claim that I don’t need unit tests, just that I don’t use them. I’m sure my code would be more robust if bolstered with unit tests, but I’m not sure of the cost:benefit ratio. Had I a team with sufficient resources, I’d probably be on the unit test side of the fence (but probably only for such direct cases, as suggested by ags1).
Well, I’ve never needed them in 30 odd years No point in starting now.
Often I’ve wished for design-by-contract though.
Just noticed Eclipse 4 now has support for @NotNull and @Nullable annotations. Sweet.
Cas
Contracts are awesome. One of the JSRs that looks like it’s moving forward has a few contract annotations.
I think that a lot of the current push for TDD comes from the dynamic languages / Web development camp where tests largely compensate for the fact that these languages don’t have types, i.e.: as Cas said, it’s a crutch for shit languages.
Cool, so it’s caught up to IDEA from six years ago.