Unit tests (Part 3)

Simon Richardson — Fri, 06 Aug 2010 08:55:33 +0000

I was meant to finish this article ages ago, sorry for the late response. I was going to talk about my experiences when using Flex Unit and ASUnit. Both have there strong and weak points and each can be easily broken down to nth degree, but I’ll just say it extremely simply. If you want to use a CIServer then from my experience then use Flex Unit, it’s more tightly integrated with various servers. I’m not saying that ASUnit doesn’t integrate with a CIServer, I’m saying that Flex Unit currently does it a lot better. Flex Unit will tackle both pure ActionScript and Flex, so should be able to tackle anything you can throw at it. ASUnit will mainly tackle ActionScript, I’ve not tried it out with Flex, just because I’ve not had the time. Let me know if you have!

Also to note that if you like metadata with in your flash apps then Flex Unit will also be a benefit. I’m not a huge fan as I can’t use static naming for the strings within metadata and you have to be hugely careful about how you spell things, also I like the DRY principal where you write once! Failure of the language if you ask me.

Unit tests (Part 1)

Simon Richardson — Thu, 22 Apr 2010 16:47:24 +0000

I’ve been tasked recently to try and get a Continuous Integration (CI) server up and running. The reason for this piece of R&D was because we had a scrum workshop and it became apparent that this could help us with our own frameworks. The interesting fact that was brought up from the workshop was; when developing software, you will spend most of the time maintaining the product after the first release. I’ve been on 3 major pieces of software in the last 2 years, each really exhaustive in the way of how much content we need to display with in very limited device setups. Every time we spend more time on maintenance than on developing the piece. When developing for devices there is even more of a watchful eye on the memory and cpu allocations, out of memory are frequent. It’s also important to note that users don’t follow the happy root that the UX people designed for, they will always find ways to “improve” it! I personally belief that software has a longer life cycle than a website and it’s this life cycle that we have to be careful for new bugs and regressions.

One possible way to help solve this would be to introduce testers, this is great, but keeping testers on the pay role constantly testing everything is very expensive. So if we as developers can help testers find an issue before testing software, they will thank-you (not forgetting your Finance guys and clients!). Testers don’t want to test buggy software because of some regression when happened to find it into your software somehow. So if we could introduce steps in between developers coding the software and releasing it to testers then I’m all for that.

This is where Unit Tests come in. Now I’m not saying you can test everything 100% (UI is extremely hard!), but what I am saying is that you should be testing the places in your code that get hit hard and often. I’m sold, it makes complete sense, those that don’t see the benefits of unit testing in software are just making mistakes for themselves to pick up later on and it will cost you massively. And it’s not just cost, it’s time and as a developer do you really want to spend the next 6 months fixing simple mistakes that you accidentally made 8 months ago.

In my eyes, unit tests help produce high quality code because it reduces the errors that hit your users – it’s that simple!

Part 2: How to setup CI

simonrichardson.info » Unit Testing

Unit tests (Part 3)

Unit tests (Part 1)