Comments on: Who Has Time for Unit Tests?

By: George

George — Tue, 08 Jan 2008 20:02:07 +0000

Yeah, nice post I read several times especially for upcoming comments. I totally agree with what Abdul and Todd talked here. Unfortunately I got hungup on Scrums that the manager asked and I could never have enough hours, but luckly I was not asked for unit testing as I’m the only Flex developer in the team.
The lowest hanging fruit for me is also the service interaction with backend which developing in parallel. What I can do, was to make robust service classes with fault checking etc, and most important, tracing all information from backend out at run-time so any ‘testers’ can find bugs with browser easily.
I don’t think TDD could be fit with most of Flex teams, usability/functional testing more important than unit testing in Flex. Instead you should write safe code, checking exceptions as much as possible in your functions, tracing run-time informations. Save your hours to improve usabilities and application designs.

By: Todd

Todd — Tue, 08 Jan 2008 15:46:12 +0000

Don’t get hungup on any particulars of TDD, SCRUM, XP, etc. I’ve yet to work on a project where everything is tied to one textbook methodology. Most teams usually come to their own consensus for the requirements for testing.

One of the side effects I like of having unit tests is that when a new dev comes to the team, they can run a particular test that starts executing some complex code and they can step through it in the debugger. For example, if you have a complex services layer making WebService calls and parsing XML, they can run the one test that executes the code without using the front-end and they can get a quick understanding, simply.

Also, I wouldn’t worry about the zealot proponents say about everything needing to be tested and that 50% of the code you write should be Unit Tests. While these are great goals, you’ll be doing stellar if you’re testing 80% of code with 5% of the effort. I.e., grab the lowest hanging fruit first. For me the lowest hanging fruit is always the service interaction with the backend. Since the backend changes a lot, I feel that this is teh really important stuff to have unit tests around. Some other low-hanging fruit is writing your unit tests testing actual flows/stories of the application, and not getting hungup on testing each little line of code. Some proponents of TDD get really hung up on this stuff and are really religious about lambasting someone doing this. They cite things like: Single REsponsibility Principle, never use the debugger (your unit tests should be robust enough to tell which line of code failed), 100% code coverage.

I’ve been on Java and .NET projects where the architect was so strict at TDD that we weren’t able to use any of the built-in ASP.NET components for the sake of building an application that was Testable. I left the project after a year, and rumor has it they’re still not done. But they do have a ton of unit tests. This approach isn’t good either.

Really, providing a suite of Unit Tests to a client needs to be part of the required delivery, since it does have a cost associated with it. Afterall, you’re writing code, and there is test code that needs to be maintained, and this doesn’t come for free.

And most of all, remember that quality software has been being built for years without TDD. TDD != Quality and it’s not a panacea, but it is a set of ideas that can help you deliver something robust and timely.

By: Brian Deitte

Brian Deitte — Sun, 06 Jan 2008 20:11:59 +0000

I’m guessing that not seeing a project at a later point are preventing you from seeing the need for unit testing. I don’t know if you see projects later when consulting, but the main benefit (although not the only benefit) I see in unit tests is the ability to change things without worrying about breaking random things. This happens when months or years have gone by since I’ve touched the code or when someone new is working on a project The code becomes a lot less brittle to new changes with unit tests. Perhaps you don’t see this because in consulting the projects just go away? Or the projects won’t be around long enough to benefit from this?

I don’t think there’s any need for a solid base design or specific requirements to do unit testing. Functionality testing may require better requirements, but unit testing just requires time to think about how the code should work. Which brings up another benefit, which is that unit tests often find bugs before they become bugs.

If done right, it isn’t just cookie cutter tests, and it takes time. And of course that will be just as hard to justify to some companies as Cairngorm.

By: Robert

Robert — Sun, 06 Jan 2008 18:27:45 +0000

@ Valentin

“At the beginning of a project I usually try to plan everything from the whole architecture to buttons onRollOver effects.”

That is insane. TDD does not even attempt to do this. I really pity you if you try and do that.

By: Valentin Simonov

Valentin Simonov — Sat, 05 Jan 2008 12:19:25 +0000

I’m usually coding a project alone. I’m teamed with designers, a back-end programmer, sometimes using components from other developers. At the beginning of a project I usually try to plan everything from the whole architecture to buttons onRollOver effects. And I start with clear good documented OOP code. But soon I have to write code faster, I have to apply multiple changes many of which are hard with current project structure, so I’m making hacks and fixes. So all good OOP code approach fails miserably.

I seriously laughed at “The funny thing about OOP in Flash is how quickly it dies a pathetic little death when a deadline rears its head.” and the button example. Because it’s so true.

But, I’m coding a huge flex project atm and seriously considering to start using unit tests.