Sometimes, software development projects do not go as we want...
Here, maybe frightened by technical issues, we first set out to solve the technical requirements, while setting aside the design phase.
It was to trigger a flash game via a push button that writes to the serial port.
But the flash player does not have access to low-level devices, so we built a bridge between the os and Flex, with a small Java program that relays messages from the serial port to a TCP socket.
The problem was that once these uncertainties removed, we directly begun development, without a true model of the application.
If one day you are offered such a deal, get out!
For me I stayed, and now 2 years have gone...
Of course, we recently had to deliver the product to the customer, and thus we were compelled to refactor the code to produce something that is up to the Tanukis web-studio quality requirement...
This is not the game code, but the Air application that configures it. Obviously, being a commercial project, I could not deliver the sources.
Here we go, 10 days Tanukis refactoring crash-course!
At-work, with the Tanukis (dream) team, we talk a lot of quality:
- how to improve our deliverables,
- develop our process for maxim productivity
- reduce time spent in debugging ...
- to increase time for our creations
As a developer, I am convinced that the only way to produce bullet-proof code is to accompany each class with a unit-test twin. On small projects, it may be possible to produce quality code without automated testing procedure. But when a project becomes important enough that a developer can no longer represent-it completely in his memory, we should create a test procedure (maybe, it's too late...). How can I be sure that the code added (or modified) by a developer A will not break the previous developer's code B? If the project has a test suite, we have only to run it to validate the newly added code. This is the regression testing principle: use a group of unit tests to validate the overall operation of a project. If I'm proselytizing for unit-test use in enterprise business is that despite the overload time it implies, I am confident that ultimately, this effort will pay because time spent to debug will be proportionately lower.
I'm not a sociologist of work, but ... Same project, 2 dev teams: a team that tests its code, the other not. Which will deliver its project first ? I have my own ideas on the issue...
Well, enough talk. I suggest to use FlexUnit 4 for unit testing a small file upload application: server-side code, events, data-binding, this project offers the advantage of being complete and therefore perfect for exploring the range of possibilities that supply FlexUnit 4. I chose FlexUnit because I love the Flex open-source Framework. In addition, FlexUnit is natively integrated in FlashBuilder, it is entirely consistent with Flex4, and the mixture of reflection API and metadata-tag produce beautiful and elegant testing syntax. However, other solutions exist, even if I've not had the opportunity to try them:
- ASunit, historical solution, Flex devoid, for pure-juice flashers...
- Fluint, another historical solution. The FlexUnit wiki made constant reference to this library
- FUnit, another test library, met thanks to Google
I'am not an AS3 guru, maybe you'll found some big flash error in my code. I just want to share my (small) FlexUnit knowledge. I am passionate about my work, I am an avid reader and I have in me well done work love ;-) So, let's go [ in part 2, we'll see how-to test in the real world: mocking, functional testing, ... ] ...