Over the last two years I have had the opportunity to work on two projects developing rich internet applications using Adobe Flex. These projects are being developed at separate companies but both share an interesting aspect in common. Neither project uses unit testing as an everyday tool when developing Flex code. Given the lack of community discussion around the topic I find it hard to believe that these are isolated cases.
The guys over at Adobe are doing some great work on a major new release of Flex Unit. A new version of Flex Builder is looming around the corner with some very promising unit test integration. There is a great example of how to set up Flex Unit on a continuos integration server. There is even a test coverage analysis tool that has been under steady development for the last year. There is all this great stuff out there yet as a community we still aren’t taking advantage of it… what’s going on?
I’ve decided that it’s time for me to demonstrate initiative and make a change. I’m challenging myself to spend the next couple of weeks sharing some of my experiences I have had while writing Flex unit tests over the last few months. I’ll look at some simple examples that can help beginners getting started as well as examining techniques for dealing with some of the tricker problems you may encounter.
public function canYouContribute(): void {
Alert.show("Yes", "Yes! I can!", Alert.YES);
}
I’d love to hear from you about which problems you would like to see discussed or titbits that you think would be worth sharing with others. I certainly can’t do it alone!
I’ve never really understood the concept of unit testing, but I’m willing to take the challenge too.
It prooves your code work ;p
Definitely options for mocks and test data would be of interest, great idea to start sharing experiences and I think your timing is perfect as I think alot of Flex devs are ever-increasingly aware they perhaps should be unit testing but definitely has a somewhat elitist or black magic perception in the community.
That’s a great idea Danny, I think more knowledge about mocking in flex/actionscript is one area that everyone including myself could benefit from.
Surely, unit-testing is a development time/code quality tradeoff. Having read some of your examples now, it doesn’t seem like it’s worth the cost in development time for GUI components, or, in most cases, Flex in general. Flex is by definition a client-side technology. You should never, ever trust the client so before anything is committed to the database on the server-side it should be strcitly validated and checked for errors (unit testing makes sense here). Should you compromise on code-quality (for GUIs)? Yes, I think it’s acceptable if it means development time will be much less. Just get good at programming and there shouldn’t be many bugs to start with. Structure your code well and the bugs that are found will be easy to isolate and fix.
Think of it like this. You’re a journalist for the NY Times. All your work is checked by two editors. Once every couple of months a typo or two makes it through. Does this mean that all your work should now be checked by four editors? I don’t think so…
Looks like I didn’t strictly validate the word ‘strictly’ in the above comment
@Darren
Thanks for your comment. I won’t argue with you that there is a cost associated with unit testing. However I will say that regardless of how perfect your code is you will always have to test it before you release it. I used to spend a lot of time manually testing my code, now I spend that time writing automated tests.
If you don’t see unit testing ever becoming part of your day to day development there is nothing wrong with that. However I challenge you the next time you discover a bug in your production code to see if you can write a unit test that identifies it
I’m 100% for unit testing. And FlexUnit 4 is a great tool. However, to apply it to Cairngorm architecture, which is mandatory in our shop, is a challenge. There is very little on this topic. If you can help to any degree in this direction, I’d really appreciate it.
Try mockito-flex if you need to mock anything. It won’t give you hangover and it tastes really well: http://bitbucket.org/loomis/mockito-flex/
@Stan
I’m more than happy to help out, I haven’t used Cairngorm myself but if you can give me an example of what parts you are finding difficult or you can point me in the right direction I’ll see what I can come up with
I think the point of Unit testing is missed by some of the comments here. Unit testing is not about finding bugs in the code like this article says: http://blog.codeville.net/2009/08/24/writing-great-unit-tests-best-and-worst-practises/. It’s actually a “tool”, a blue-print if you like, of what your code should do…that is why unit test are written before any code is created…it’s like our professors always said: before you write any code, put it down on paper” -> same idea, different method.