1
edit
Changes
no edit summary
===Is it worth it... really??===
Test driven development begins with the notion that before writing and code, you should have a well thought out design. You should prototype all of your classes and functions, and know their behaviors ahead of time. What this allows you to do, is to write tests that check and constrain the behavior of these classes and functions to ensure that they do exactly what you want them to. Assuming your design is correct, and that the unit tests verify the behavior of the classes and functions, all that remains are "implementation details". Your implementation must pass all the tests you've written, and then you can fiddle with improving the efficiency of an implementation, after correctness is ensured.
But what if you've already written the bulk of your application already, and are pretty darn sure that it's mostly correct? Unit tests offer the benefit that whenever you change something, you can run your unit tests again, and if they all pass, you can be confident that you haven't broken anything. Sometimes when you fix a bug, you accidentally introduce a new one... but with unit tests you can simply run them again to make sure that you haven't, AND write a new unit test to ensure that the bug you fixed doesn't get re-introduced in the future.
Therefore, unit testing makes your application easier to re-factor. But, unit tests do indeed make it harder to redesign your application. If you change the behavior of a class or function, or remove legacy code, this will cause unit tests to fail. If you code your application 'as you go', without any forethought on the design, then unit tests will make your job harder. In a sense though, this is not a real problem, since all that this implies is that unit testing forces you to think about good design ahead of time, instead of just hacking along.
===How many unit tests should a function get?===
There is no definite answer to this question, but some general guidelines that I like are:
*Don't test the language or the framework. If you are using a framework or library for your application, and the documentation tells you what the behavior of a function or class is, don't test it. If it fails to do what it is supposed to, this is a bug in the framework, library, or language implementation, but not your application.
*Each control structure (branching, looping, jumping/breaking, returning from a function) adds one more unit test to the function.
*Each special case deserves a unit test (maybe you want your function to return null in some cases, or throw an exception in response to an argument having a specific value). Generally, each way your function can possibly be ended, adds one more unit test to that function.
*Each event that gets dispatched adds one more unit test.
==Flex Unit Testing and Mockolate Unit Testing Frameworks==
|Chat||PrivateChatMessage||None||Too simple, not worth testing. ||ima github link
|-
|Presentation||Presentation||Not started. Complete || - ||ima github link
|-
|Presentation||PresentationList||Not started. Complete || - ||ima github link
|-
|Presentation||Slide||Not started. Complete || - ||ima github link
|-
|User||User||None||Too simple. Not worth testing. ||ima github link
