1
edit
Changes
no edit summary
==Flex Unit Testing and Mockolate Unit Testing Frameworks==
For general information on stubbing and mocking, see the following resources:
*
From FlexUnit, the main
The code for each module's model does not contains very many dependencies on other classes. Therefore, testing the model was fairly
===Resources===
==Mobile Client Unit Testing Idioms==
===The Model===
The way I tested the model made no use of the Mockolate framework. This is because the code for each module's model does not contains very many dependencies on other classes, and the need to create mocks and stubs wasn't there. Most unit tests simply invoked a functions, and used a " assertThat(<VALUE1>, equalTo(<VALUE2>));" statement to verify that the function produced the desired effect. If you've ever done any kind of simple testing using C's assert macro, this does basically the same thing, namely verifies that <VALUE1> is identical with <VALUE2>.
The only tricky part that took a while to figure out, was verifying that a signal gets dispatched under certain conditions, and that the values that these signals were dispatched with, were what they were supposed to be. Mockolate allows "spying" on classes to verify their behavior, but unfortunately this only works if the signals are mocked by the framework, which requires them to be public fields. In the mobile application, they are not public, and have no setters, so this was not (as far as I could figure out) possible.
The flow for unit testing these things was as follows. First, code a listener method that is to verify the values that the signal is dispatched. The verification can be done simply with "assertThat(...)". Add this 'verification' method as a listener to the signal that you want to check. Second, you are going to dispatch a custom event in this verification method, that will be used in the next step. Next, in the test case, use "Async.proceedOnEvent(...)", to listen for the custom event that you dispatch from your verification method. The Async.proceedOnEvent(...) will cause the unit test to fail if the event you are listening for does not get dispatched. This solution allows you to test that the signal was both dispatched, and with the correct values. If the signal does not get dispatched, then the verification method will never get called, and will never dispatch the event that the "Async" is waiting for, causing the unit test to fail. If the signal is dispatched, but with the wrong values, it will cause the "assertThat" checks to fail. Any further checks on the class should also be done here, because signal are dispatched asynchronously.
For an example of all this stuff, see the ****: GITUHB LINK
===The Commands===
===The View Mediators===
==Unit Tests Coverage, Notes==
The mobile client was initially structured using the Model-View-Controller (MVC) design pattern. As time went on the code base got scattered in a way that is not entirely in keeping with the design pattern. The mobile client's code is divided into four main parts: models, views, core, and commands. The meanings of "model" and "view" are the same as in the MVC design pattern. The "command" part of the application consists of signal-command pairs. .... The "core" component is where most of the code that communicate with a BigBlueButton server ended up. I don't think this part of the application should be unit tested for two main reasons. First, most of the code in the "core" is simple, and repeats the same pattern over and over again. Second, unit testing this part of the application may make it more "brittle". This is because any time the message format for communication between client and server changes (not an infrequent occurrence), the unit tests will also need to be redesigned or they will fail. ===Model Unit Tests(COMPLETE)===
'' <span style="color: red;">***Github links coming soon... ***</span>''
|-
|User||UserUISession||Complete|| - ||ima github link
|-
|}
===Controller (Commands) Unit Tests===
'' <span style="color: red;">***Github links coming soon... ***</span>''
{|cellspacing="0" width="100%" cellpadding="5" border="1"
|-
!Command Name!!Unit Tests? (Yes/No)!!Coverage!!Notes!!Github
|-
|CameraQualityCommand||Yes||Complete||-||ima github link
|-
|ConnectCommand||Yes||Complete|| - ||ima github link
|-
|DisconnectUserCommand||-||-|| - ||ima github link
|-
|JoinMeetingCommand||-||-||-||ima github link
|-
|LoadSlideCommand||-||-||-||ima github link
|-
|MicrophoneMuteCommand||Yes||Complete|| - ||ima github link
|-
|NavigateToCommand||-||-||-||ima github link
|-
|RaiseHandCommand||-||-|| - ||ima github link
|-
|RemovePageCommand||-||-||-||ima github link
|-
|ShareCameraCommand||Yes||Complete||-||ima github link
|-
|ShareMicrophoneCommand||Yes||Complete||-||ima github link
|-
|blankity||blank||blank|| template ||ima github link
|-
|}
