Who Has Time for Unit Tests?

A couple months ago, I read about dpUInt, yet another unit testing framework for Flex. I got it from reading the docs, it seemed easy to add to an existing or new project, and I’m all gung ho for giving it a try. If it sucks, I know I have both FlexUnit and VisualFlexUnit as back up frameworks.

Test Driven Development practitioners are very passionate about what they do. They give off this air that my early OOP mentor’s also did, “Once you go TDD, you never go back”. The funny thing about OOP in Flash is how quickly it dies a pathetic little death when a deadline rears its head.

The amount of sustainable OOP in Flash is proportional to the deadline length. If I have 2 months, classes & framework for the win. If I have 2 days, screw you, on(press) { copyPasteCodeOnObjectsAndInFrames(); } and then show client early ’cause you know they’ll have massive changes.

Is unit testing like this? When I read Peter Bell’s blog, and other unit testing scenarios, I get the sense that an existing solid software base is used. Templates are modified, run through tests to ensure the new code & design works, and then the code is deployed. This cookie cutter pattern repeats, and can repeat, because the original software is solid, is customizable for a wide variety of common customer needs, and unit tests ensure everything keeps humming along.

The other sense I get is developers already know what they’re going to write.

I’ve never been in either scenario. Either I’ve had to build from scratch, re-write from scratch, or build atop of crap because the client heard “re-write” and thus freaked out (thus re-writing from scratch). Even in the best planned waterfall based projects with good IA’s, and somewhat flexible deadlines, it’s always been a process of discovery, modified requirements, and re-factoring/re-coding. This is in partly why I enjoy programming in Flash & Flex. Not only do I get to do that stuff with code, but also with design.

Therefore, it’s really hard for me to imagine how I could START writing test cases first in my project. The closest I’ve come to writing “tests” is when I create a new FLA to test a component that’s acting weird. Instead of testing the entire project, I’ll just boot up a new FLA in Flash, import the component, create it, throw some fake data at it and see what happens. In this way, I can more quickly find the problem, AND re-use the testing FLA (70% of the FLA’s anyway) at a later date if the component acts up again. This is after the fact, though.

The same thing in Flex. If I inspect the HTTP traffic through Charles, and see that the webservice is returning everything fine, and debugging doesn’t reveal anything obvious, I’ll set up a test file that instantiates controls in a really simple environment. Instead of a large app, it’s 2 controls that interact with simple fake data. Again, this really helps me isolate problems and more easily find them. It also makes it easier for me to not only test later, but quickly test smaller portions of my code.

Granted, sometimes I don’t like “going to all that trouble” and keep doing risk debugging; where you swear that in just 1 more compile you’ll find the bug and fix it… yet this is the 4th time you’ve said that and you could of already been well on your way creating a test harness to more quickly and assuredly find and fix the problem…

Again, though, after the fact.

Like everything in programming, I’m still reading more sources to get a better idea, it’s just hard to get a good feel for who in the Flex & Flash community is doing unit testing, and how. With the influx of traditional developers in the Flex world, I’m seeing more talk about it, yet not enough case studies with good details on how the work flow actually works from requirements gathering to sitting down and coding. Flash devs’ll try anything, just point us to the right way!

People would ask me to justify the time it takes to actually use Cairngorm. In their example code, all they really did was neatly wrap 1 line of code setting 1 variable on a single ModelLocator in a Command. I’d respond that either they wait 3 months, and compare the newest Command in SVN with the one they emailed me to get their answer. If that didn’t make any sense, or they just didn’t want to have faith in JXL, I’d instead point them to a lighter weight framework.

Am I in the same predicament? Are my deadlines, lack of hardcore requirements, and/or inability to easily articulate a base design preventing me from really benefiting from formal unit testing or do I just need to read more?

8 Replies to “Who Has Time for Unit Tests?”

  1. I don’t think you either need to have a hardcore requirement document or read more about the subject. What you need is to get a pet project up and running using TDD.

    I come from the same background as you: I grew up and studied in the graphics world (3d and 2d) and slowly moved to programming. I know how easy it is to “hack it” in Flash (although I never used the on(Press) way… it’s Satan’s dialect). Like OOP, TDD is hard to grasp at first, at least for me. I need to hammer at it until I “get it”. Once you break your nose against a brick wall once or twice and finally see the light, it becomes second nature.

    These days, even when I hack my way through an unrealistic deadline, I still use OOP heavily, although with a less architected approach (I call that the “I can do it in 5 mins” syndrome). I’m slowly getting to that with TDD as well.

    Try it ;)

  2. I think you’re also overlooking (or rather not mentioning) the key benefit of TDD, rather than how quickly you can debug a problem using Charles or a mini-fla. How about the fact that you know there is a problem before even you or anyone else has seen the compiled product? That reassurance alone that you are much less likely to deliver a bugged out product is worth it’s weight in time. Change this bit of code here and blamo you see what you narked up somewhere else.

  3. If you are only developer on a project, you know what you did and what you broke. Tests (unit or functional) are very effective when multiple developers are involved. Sometimes, tests also help, if you are refactoring some old code-base (written by you or someone else)…

    Doesn’t make sense in small projects, because entire code fits into your mind easily. As project grows to thousands of lines of code with multiple different modules written by you/someone, its hard to track all details, which you could do in small projects using manual-tests (as you mentioned using fla etc)…

    I am not relgious about any one methodlogy.. But I have seen some benefits from unit-tests.

    The downside is, I have seen people getting addicted of this approach and overuse it to kill the productivity. I have seen some guys writing test cases for the sake of writing (or having a test class corresponding to a class)… I think, tests cases are made around boundary-conditions. If you start writing tests for everything, you would be less careful while writing the code, assuming my tests would catch, if there is any bug or QA team would take care of it :-)

    Anyway, as said, there is no strict rule, it all depends on the requirements. Probably, in some project (which grows over the year) you might feel a need to use unit-tests, probably some library or framework, probably the one used by lots of people.

    Having said all that, I also do what you do (quick fla test or simple tests) most of the time. But I do write unit tests sometimes, if I feel the requirement..

    Long comment, sorry for repeats…


  4. 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.

  5. @ 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.

  6. 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.

  7. 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.

  8. 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.

Comments are closed.