Version 0.1 of slides are attached.
- Refactoring and Unit Testing in Sakai
- Point -> write code that is correct and easy to change
- Defns
- a)unit testing - logic testing
b)integration testing - testing in context
c)refactoring - change code organization (not functionality) for clarity, correctness and decoupling
- a)unit testing - logic testing
- why Unit and Integration testing?
a)Decoupled code
b)clearer code
c)testable code - Why refactoring?
a)Enable addition of features
b)fix bugs
c)avoid code terror - combine and support each other
a)refactor -> change
b)change -> testing (errors)
c)unit testing catches logic errors
d)unit testing implies change code to be testable
e)can't slap in UT since it requires code change (refactoring)
f)can't slap in refactoring (change implies error)
g)so put both in.
- Goals of talk
introduce Unit testing, integration testing, and refactoring
give example of doing it. - Example
- SQL in Sakai is intertwined with code
- Hard to add new sql
a)find a lot of spots to change
b)change a lot of code in many places
c)have to test changes in context of complete implementation - Need to add new SQL
a)tweaking (UMich needed to add something just for Oracle
b)add new dialects - Want to isolate SQL
a)testing
b)simply decouple code - Event implementation
- refactor and unit test
add some detail about code
Do a walk through using Eclipse tools of:- making method for the text
- extracting dialect logic into methods
- moving methods to separate class>
- integration test (Josh)
- refactor and unit test
Ignore anything after this:
To run itests
- compile / deploy sakai into your standard maven.tomcat.home directory.
- setup _maven.tomcat.home/sakai/sakai.properties file (for hsqldb by default) necessary if want to use hsql?
- run maven itest goal with -Dmaven.test.skip=false