TESTING
=-=-=-=-=-=-=-=-=

Unit Testing
\/
Integration Testing
\/
Validation Testing

Test small pieces first --> then larger pieces. The same way we would if we were coding -- again, thinking iteratively.

Test the UI


Mocking
http://easymock.org/getting-started.html


-------------------


Since we are keen to continue with working on LORS -- today lets focus on more testing with LORS: and think about mocking a little more, and how we might start to perform more complex tests which cover more of the application.

Unit Testing
-----------------
We test a single UNIT of code in ISOLATION -- typically a class, we can write a few tests for each method on the class. We've already started doing this for the FactoryUtil and the DAO class and models.

Now, lets test the servlets -- effectively unit testing the servlet -- except that the servlets are more difficult to test in isolation, they have more dependencies. This is because we have effectively moved a "layer upwards".
(Our models are independent of the controller, so we can test them in isolation -- but our controller servlets depend on the model (and container context) -- this will affect how we can test, and means we'll need to think about mocking)

###We could mock all of the model objects and so forth -- quite reasonable, but this is a lot of work, and we may have already tested them. 
Mock the 

So instead we could just test them together with the components underneath which support them -- the models, etc.

http://httpunit.sourceforge.net/doc/servletunit-intro.html

Now if we think about it -- the servlets which support the web interface return HTML and JavaScript -- i.e. user interface -- 
difficult to test these in the usual assertions -- so these would perhaps be best tested by automating the browser.

However, the Servlets which support the mobile device API would be ideal to test.

We can directly check the JSON response objects to see if they are correct.

Difficulties?...(THINKING OBJECTIVE)

- The database.
	we can use "lors-test" just as I set one up before.
- The data in it.
	we need to perform some initial seeding.
- The hibernate session. 
	the filter may not be activated by the test -- we'll need to create it manually and add it to the request object.
	this also allows us to "mock" the database by using a session associated with the test database.
- Authentication
	How does the authentication mechanism work at present?	

Step 2)
Also, we'd ideally like to test that the Servlets work together -- if I perform an action -- I can then retrieve that action.

=======================

The other half of you -- Testing the Android.

http://developer.android.com/tools/testing/testing_android.html

Issues 
	-- Dependencies -- barcode scanning 
		-- how can we mock it?  Hint: we may need to refactor the code.
	-- SQLLite?
		-- are we using it?
	-- LORS Web API
		-- how can we mock it? Hint: we may need to refactor the code. We don't really want to rely on a server for testing the app to begin with. It would be nice if they were separate.