BigBlueButton Mobile Client Unit Tests

***Under construction!!!***

Unit Testing Philosophy

What is unit testing? Why bother?

Anyone who writes any sort of non-trivial code knows that mistakes are very easy to make. Overlooking special edge cases, or failing to do null checks when they are not enforced by the way your code is typed, for example, can cause your application to crash. Being certain that the code you write is absolutely correct is a difficult problem to solve. Unit testing aims to partially solve this problem, building on the insight that if all of the parts of a program do the correct thing, then the program as a whole will do the correct thing. Therefore, we should aim to test the parts of an application as exhaustively as possible. The parts we test (typically functions or classes) are called 'units'.

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.
• Don't test simple getters and setters. By "simple setter", I mean a method that accept a single argument, and simply sets the value of a field to the value of that argument. By "simple getter", I mean a method that accepts no arguments, and simply returns a value of a field.
• 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.

Unit Tests Coverage, Notes

Model Unit Tests

***Github links coming soon... ***

Module	Class Name	Coverage	Notes	Github
Chat	ChatMessage	Complete	Simple class. The tests just make sure that XML tags are stripped from chat messages.	ima github link
Chat	ChatMessages	Complete	-	ima github link
Chat	ChatMessagesSession	Complete	-	ima github link
Chat	ChatMessageVO	None	Too simple. Not worth testing.	ima github link
Chat	PrivateChatMessage	None	Too simple, not worth testing.	ima github link
Presentation	Presentation	Complete	-	ima github link
Presentation	PresentationList	Complete	Very simple, almost not worth testing?	ima github link
Presentation	Slide	Complete	-	ima github link
User	User	None	Too simple. Not worth testing.	ima github link
User	UserList	Complete	Big class. Large number of unit tests...	ima github link
User	UserSession	None	Too Simple. Not worth testing.	ima github link
User	UserUISession	Complete	-	ima github link