1. Spring/Testing Training Jay Sissom

2. Topics Java Interfaces Service Oriented Architecture Spring Testing with junit

3. Exercise 1 Check out FPS/TRAINING/INTERFACE1 Open edu.iu.uis.Main.java Create instances for each pet Put them all in a collection Iterate through the collection and print each pet’s name and make it speak (Don’t modify Cat & Dog classes) Hint: instanceof

4. Java Interface An Interface is a special Java class that defines behavior but doesn’t implement the behavior It defines what another object will do, not how it does it It is used to declare methods that an object must implement Use of interfaces allows objects to be dependant on behavior, but not specific object instances

5. Java Interface By using Interfaces, you don’t hard code which object must provide a service for you The object providing the service can be any object that implements the required interface

6. Java Interface An example is Collection. A Collection must allow you to:  Add items  Clear all items  Remove items  Get the size  Get an iterator to all members  (among other things) http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html

7. Java Interface Many objects implement the Collection interface  ArrayList  Vector  LinkedList  And the list goes on…. http://java.sun.com/j2se/1.4.2/docs/api/java/util/LinkedList.html

8. Java Interface You can create your own Java interface: public interface Worker { public Collection getData(); public void doWork(); }

9. Java Interface Any number of classes can implement your interface: public class MyWork implements Worker { public Collection getData() { return new ArrayList(); } public void doWork() { // Pretend I’m working }

10. Java Interface Your interface can be used in place of an object name: public Worker getMyWorker() … public void doStuff(Worker w) … When doing this, your code isn’t dependent on a single implementation of Worker. Any implementation will do.

11. Exercise 2 Use interface1 project (or check out FPS/TRAINING/INTERFACE1ANSWER if you didn’t finish Exercise 1) Create a Pet interface that defines the common functionality in Cat & Dog Change Cat & Dog to implement this interface Change Main to use the interface instead of specific instances Extra Credit: Add a Parrot object and use it

12. Inheritance Inheritance is a parent child relationship between classes Children inherit a parent’s functionality Animal public String speak(); public String getName(); Dog

13. Inheritance Inheritence implies that all children will have the functionality defined in the parent You have to be very careful when designing inheritance Animal public String speak(); public String getName(); AntDonGrinstead

14. Solution with Interfaces Using interfaces in this case would be more accurate Named > public String getName(); AntDonGrinstead Speaker > public String speak();

15. Inheritance/Interfaces IssueInterfaceInheritance How Many per classAny numberOne parent per child Inherit method signatures Yes Inherit functionalityNoYes

16. Interface Conclusion A Java Interface defines what implementing objects do, not how they do it Using interfaces will decouple your code from dependant objects. This will make it easier to maintain the code in the future

17. Exercise 3 Check out FPS/TRAINING/INTERFACE3 Create an implementation of OrderCalculator that calculates sales tax as 6% if from Indiana, 0 if from another state Shipping is $20 if another state, $15 if Indiana Change Main to use this interface Modify the interface to add this method: public double getOrderTotal(Order o); that returns the total of the order with tax & shipping Modify Main to use this method Make sure you modify both implementations to implement this interface

18. Interfaces Pt 2 We still had to put the name of the implementation class in our last example If we used that throughout our application, we’d need to change it everywhere This is still a problem

19. Interfaces Pt 2 A solution is to create a new class that has a method to return the implementation we want public OrderCalculator getInstance(); This allows us to specify our implementation once for the whole app This is called the Factory pattern

20. Exercise 4 Use interface3 project Create OrderCalculatorFactory class that has one method public OrderCalculator getInstance(); This method should return an instance of your order calculator class Change Main to use the factory

21. Interfaces Pt 3 Now we specified the implementation class in one place in our app This is better, but it would be best if the implementation class name wasn’t in Java code We can put this class name in a properties file. The factory can read the properties file to determine the class name Now the class name isn’t in compiled Java code. See FPS/TRAINING/INTERFACE4ANSWER2 for an example

22. Interfaces Pt 3 Now we need a Factory, Interface and properties file for each class This is too much work! We could build a Factory framework so we need one factory and properties file for our app Or we could use an open source framework called Spring

23. Spring Spring Mission Statement  J2EE should be easier to use  It's best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.  JavaBeans offer a great way of configuring applications.  OO design is more important than any implementation technology, such as J2EE.  Checked exceptions are overused in Java. A framework shouldn't force you to catch exceptions you're unlikely to be able to recover from.  Testability is essential, and a framework such as Spring should help make your code easier to test.

24. Spring Spring can replace our factory classes and properties file All classes can be defined to spring and we don’t need to write custom factories See FPS/TRAINING/SPRING1ANSWER

25. Spring Objects are defined as “beans” in a spring xml file: The object is accessed via the beanFactory: OrderCalculator oc = (OrderCalculator)factory.getBean("OrderCalculator");

26. Execise 5 Check out FPS/TRAINING/SPRING2 Refactor NewOrderCalculator to use MemorySalesTax object Use Spring as the factory to find the object (the beanFactory is provided for you)

27. Dependencies OrderCalculator depends on the SalesTax object to do its work Main depends on OrderCalculator When an object needs another to do its work, that is a Dependency Spring helps satisfy dependencies Using Interfaces makes it flexible

28. Dependencies To satisfy dependencies in our code we can:  Create the dependent objects using new  Use a Factory to get them  Have something external to the object create them for us The last option is called Dependency Injection or Inversion of Control

29. Inversion of Control There are three types of IoC  Constructor Based  Setter Based  Getter Based

30. Constructor Based IoC All dependent objects are passed on the constructor All dependancies are satisfied when the object is created If you have lots of dependancies, you have a huge constructor

31. Setter Based IoC All dependent objects have a setXXX method The factory will call these for each dependent object Good when there are lots of dependencies This documents the dependencies better than Constructor based IoC

32. Getter Based IoC Each object needs access to a container The object calls get methods on the container to get dependencies This is the way we have been using Spring Our code now has a dependency on Spring which may be a problem

33. Spring IoC Spring supports all three IoC types  Getter - using BeanFactory  Setter - using bean.xml  Constructor - using bean.xml The most popular is Setter based IoC This is the recommended way to handle dependencies

34. Spring Setter IoC Dependencies are mapped in the bean xml file  Update the xml to show the dependency  Create a setter method in the bean  The setter method saves the dependency to use it in the future

35. Spring Setter IoC Update the xml to show the dependency

36. Spring Setter IoC Create a setter method in the bean & save the dependency to use when necessary private SalesTax salesTax; public void setSalesTax(SalesTax st) { salesTax = st; }

37. Exercise 6 Modify the spring2 project to use setter injection in OrderCalculator Hint: You can remove the BeanFactory code in NewOrderCalculator because it isn’t necessary anymore FPS/TRAINING/SPRING2ANSWER2

38. Spring with Struts There are a few steps required to get Spring working with Struts  Starting up Spring  Location of bean xml  Spring/Struts integration

39. Starting up Spring Spring starts up with a servlet listener This code needs to be in web.xml org.springframework.web.context.ContextLoaderListener

40. Location of bean xml Spring looks for beans in /WEB-INF/applicationContext.xml This can be changed by adding the following in web.xml contextConfigLocation /WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml

41. Spring/Struts integration Spring can handle IoC in Struts Actions Define dependencies in xml file Spring calls setter methods in Struts Actions

42. Spring/Struts integration Define Struts plugin in struts-config.xml Spring looks in /WEB-INF/action-servlet.xml for Struts action bean definitions Note: action is the name of the Struts Servlet in web.xml

43. Spring/Struts integration The type of each action in struts-config.xml should be org.springframework.web.struts.DelegatingActionProxy The dependencies and actual type should be defined in action-servlet.xml Note: /path needs to match path in in struts-config.xml

44. Spring/Struts integration Struts Actions are defined in action- servlet.xml Other beans are defined in applicationContext.xml Struts actions can access beans defined in applicationContext.xml applicationContext.xml beans can’t access Struts actions

45. Exercise 7 Check out FPS/TRAINING/STRUTS1 Setup Spring for the application  Put beans in applicationContext.xml & action- servlet.xml  Put setter methods in beans  Update struts-config.xml for Spring  Update web.xml for Spring

46. Application Testing Unit Testing – Test each object as it is written Functional Testing – Test each use case to make sure it works properly Usability Testing – Test the app to make sure users understand it Load Testing – Make sure the application will perform properly under a load

47. jUnit Unit Tests are a series of tests that verify each component of your application jUnit is a framework to help standardize these tests jUnit can help automate tests so it is easy to see if a component works Open Source Framework Integrated into Eclipse and ant

48. Why Unit Test? Find bugs soon after code is written Save other team members’ time Prove that finished code works Make future maintenance easier Example of how to use code

49. Unit testing goals Each class has tests for all public methods Tests not only test successes, but also test failures Tests are organized so they are easy to run Tests are run often Each test is completely independent of other tests Each time a bug is found, write an additional test to check for that bug, then fix the bug

50. jUnit Concepts TestCase – a series of related tests  All the tests for an object  All the tests for a method TestSuite – a series of related test cases  All tests for a package  All tests for a use case  All tests for an application

51. jUnit Concepts TestRunner – jUnit code that runs tests  Command line  Swing  Eclipse

52. jUnit Addons Dbunit – code to initialize a database to a known state before testing Struts test case – Test Struts specific code using mock objects Cactus – Test HTTP applications using mock objects HttpUnit – Test HTTP applications based on an embedded servlet container

53. Writing jUnit tests Subclass junit.framework.TestCase Create a constructor with a single String parameter. Call super(string) in this constructor Write tests in methods that return void and start with test as their name Call fail, assertX in tests as necessary

54. Writing jUnit tests protected void setUp() is called before each test method protected void tearDown() is called after each test method These can be used to setup and cleanup the environment required for each test

55. Test success/failure assertX methods test for the correct values. Examples:  assertTrue/assertFalse  assertNull/assertNotNull  assertEquals Fail() method stops the test and marks it as a failure Throwing an uncaught exception marks the test as a failure

56. Test success/failure The assertEquals method takes the following arguments  String = a message that is printed if the assertion fails  Expected value = the value expected  Test value = the value to test Double & Float comparisons take a 4th argument - a precision range

57. Example test /** * Test searching for someone that doesn't exist **/ public void testGetPerson1() throws Exception{ BusinessLogic bl = (BusinessLogic)beanFactory.getBean(“BusinessLogic”); Person p = bli.getPerson("Unknown"); assertNull("Unknown person should be null",p); }

58. Exercise 8 Check out FPS/TRAINING/JUNIT1 Create a series of junit tests for the UsaTax2004Calculator object See http://www.bankrate.com/brm/itax/2004taxrates.asp for the official tax rates http://www.bankrate.com/brm/itax/2004taxrates.asp There is at least one bug in the object

59. Best Practices Make each test method only test one feature Test for success and failure Build a test suite that runs all your tests When a bug is found, write a test to find the bug, then fix the bug Write tests that don’t depend on external systems (database or GDS)

60. Best Practices Tests shouldn’t be dependent on other tests Don’t test things that can’t break Put tests in their own package Read the jUnit FAQ http://junit.sourceforge.net/doc/faq/faq.htm

61. jUnit Summary jUnit helps you create higher quality software Time spent by writing tests will be recovered many times over during future maintenance

62. Test Driven Development TDD is a standard for Kuali development and may be a future standard for UIS This completely changes the way you develop code Tests are developed before production code

63. Test Driven Development When using TDD, here is how to build functionality:  Write a single test  Compile it. It shouldn't compile, because you haven't written the implementation code it calls  Implement just enough code to get the test to compile  Run the test and see it fail  Implement just enough code to get the test to pass  Run the test and see it pass  Refactor for clarity and "once and only once"  Repeat http://xprogramming.com/xpmag/testFirstGuidelines.htmhttp://www.differentpla.net/node/view/58

64. Test Driven Development Test Driven Development (a.k.a. Test-first design ) is one of the core programming practices of XP. Many of us have learned over the years the value of writing automated tests for our code. Many of us have also learned the difficulty of writing tests after code is already in place. Test-first design takes a different, extreme approach to ensure that we test all code, all the time. The practice of test-first design begets a changed mindset: we write tests not as an afterthought to ensure our code works, but instead as just part of the everyday, every-minute way of building software. Instead of writing our detailed design specifications on paper, we write them in code. Instead of first striving to perfectly design a system on paper, we use tests to guide our design. Instead of coding for hours at a stretch, only to find our planning went awry, we use test-first design to pace ourselves, always assuring that we are moving forward correctly with each passing minute.

65. The steps Write a test that specifies a tiny bit of functionality Ensure the test fails (you haven't built the functionality yet!) Write only the code necessary to make the test pass Refactor the code, ensuring that it has the simplest design possible for the functionality built to date

66. The rules Test everything that can possibly break Tests come first All tests run at 100% all the time

67. The benefits Code is written so that modules are testable in isolation. Code written without tests in mind is often highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll devise ways of minimizing dependencies in your system in order to write your tests. The tests act as system-level documentation. They are the first client of your classes; they show how the developer intended for the class to be used.

68. The benefits The system has automated tests by definition. As your system grows, running full regression tests manually will ultimately take outrageous amounts of time. Development is paced. We specify tiny bits of functionality in our tests, then write a small amount of code to fulfill that specification. Rinse, repeat. Tiny means seconds to a few minutes. The code base progresses forward at a relatively constant rate in terms of the functionality supported.

69. Example Roman Number converter

70. Quick Review Using Java interfaces makes our code more flexible Spring is a Factory that lets us change implementations of objects without recompiling jUnit is a framework to help developers test objects TDD is really great and we’re all going to love it  We WILL use it on the next exercise!

71. Exercise 8 Create a Bowling Score Calculator Use Test Driven Development

72. Data Access With Spring Spring provides services to make writing database code easier  Automatic connection handling  Simplified data access code using templates  Declarative transaction management

73. Auto Connection Handling Spring can manage your database connection for you It is NOT a connection pool, it uses the container’s connection pool It will retrieve connections when you need them and close them when you are done This means less code for you to write

74. Template Spring provides templates for Hibernate, iBatis, JDBC, OJB and JDO A template provides  Connection management  Exception translation

75. Template DAO objects can use this template by extending a DaoSupport class For OJB, it is PersistenceBrokerDaoSupport Call getPersistenceBrokerTemplate() in code to access the template

76. Template Methods available  store() - store a persistent object  delete() - delete a persistent object  getCollectionByQuery() - get a collection  getObjectByQuery() - get an object  There are others Usually updating the database requires a one line method: public store(Object o) { getPersistenceBrokerTemplate().store(o); }

77. Example Sales Tax Application FPS/TRAINING/DAO1

78. Exercise 9 Check out FPS/TRAINING/DAO2 Write an OJB DAO according to the interface StateDao Make sure to update the applicationContext file Run the web app to see if it worked http://localhost:8080/dao2/state.do

79. Testing with Mock Objects A Mock object is like an acting double We use Java interfaces so we can swap out functionality This allows us to swap out dependent objects with Mock objects for testing With mock objects, we can test the business logic tier without talking to other systems

80. Why Mock Objects The real object has nondeterministic behavior The real object is difficult to set up The real object has behavior that is hard to trigger The real object is slow Others… Pragmatic Unit Testing

81. Mock Objects There are Mock object frameworks  jMock  EasyMock  MockCreator  Probably others OR You can create your own Mock objects

82. Mock Object A Mock object can be a simple Java object that implements the correct interface A DAO Mock Object can implement the correct interface, then each method is implemented as simply as possible You can implement the methods as needed by your test cases

83. Mock Objects Insert some really cool exercise here…

84. Declarative Transactions Spring can coordinate transactions for you in one of two ways  Programatic - in Java code  Declarative - in the applicationContext xml Using declarative transaction means less code to maintain

85. Declarative Transactions <bean id="pdpReferenceService” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml

86. Declarative Transactions <bean id="pdpReferenceService” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml Class we write

87. Declarative Transactions <bean id="pdpReferenceService” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml It calls DAOs for data access

88. Declarative Transactions <bean id=" pdpReferenceService ” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml Other beans access our code via this id

89. Declarative Transactions <bean id="pdpReferenceService” class=" org.springframework.transaction.interceptor.TransactionProxyFactoryBean" > PROPAGATION_REQUIRED Example from applicationContext.xml Spring provides a proxy class that handles transactions

90. Declarative Transactions <bean id="pdpReferenceService” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml Spring’s proxy class calls our real class

91. Declarative Transactions <bean id="pdpReferenceService” class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> PROPAGATION_REQUIRED Example from applicationContext.xml We control the type of transaction

92. Transaction Properties PROPAGATION_MANDATORY Support a current transaction, throw an exception if none exists. PROPAGATION_NEVER Execute non-transactionally, throw an exception if a transaction exists. PROPAGATION_NOT_SUPPORTED Execute non-transactionally, suspending the current transaction if one exists. PROPAGATION_REQUIRED Support a current transaction, create a new one if none exists. PROPAGATION_REQUIRES_NEW Create a new transaction, suspending the current transaction if one exists. PROPAGATION_SUPPORTS Support a current transaction, execute non-transactionally if none exists. * Not all are supported by every transaction manager.

93. Transaction Properties Properties can be applied to methods based on wildcards PROPAGATION_REQUIRED PROPAGATION_MANDATORY PROPAGATION_REQUIRED,readOnly

94. Transactions If necessary, a transaction will  Begin before the method is called  Commit after the method is finished  Rollback if the method throws a Runtime exception (not a checked exception) Rollback behavior can be controlled in the applicationContext file

95. Transactions You can control rollback & commit on specific transactions by listing them in transaction attributes PROPAGATION_REQUIRED, -MyCheckedException PROPAGATION_REQUIRED, +NullPointerException - means rollback, + means commit

96. Exercise 10 Check out FPS/TRAINING/SERVICE1 Write an implementation of OrderService Apply these business rules for a save  Use the correct part price based on quantity  If the total for a single part is > $100 give a 5% discount  If the total for a single part is > $1000 give a 6% discount  Remember TDD? Use Mock Objects for DAO’s when testing the service

97. Architecture Our systems should be designed with the following in mind:  Readability  Flexibility  Maintainability  Testable

98. Architecture The 3 tier architecture helps us meet those some of these goals Data AccessBusiness LogicUser Interface

99. Architecture Readability - All code of a specific type (data access, business logic, user interface) is in it’s own location Flexibility - ? Maintainability - See Readability Testable - ? We can do better

100. Architecture OJB or JDBC DAO OJB or JDBC DAO Service (business logic) Service (business logic) Struts Forms Struts Forms Struts Actions Struts Actions Business Objects Service InterfaceDAO Interface

101. Architecture Readability - Same as before Flexibility - Each tier talks to an interface for the other tier. The implementation can change all it wants Maintainability - See Readability Testable - We can test each tier independently by using Mock objects because they communicate via interfaces

102. DAO - Data Access Object DAO’s talk to datasources to create, retrieve, update and delete data No business logic allowed All JDBC, SQL and/or OJB features should be in these object types and no other object types Generally one DAO per table

103. DAO Interface Java interfaces for DAO objects Services should only be aware of interface, not actual DAO implementation The interface allows the use of Mock objects when testing

104. Service Used for business logic Call DAO’s and other Services to access data Should not contain SQL, JDBC or web specific information Each method will be a single database transaction

105. Service Interface Java interfaces for Service objects The interface allows the use of Mock objects when testing

106. Struts Actions Web user interface logic No business logic Call Services for business logic Generally should only call a single method in a service object

107. Struts Forms Only used when a user posts a form to the server All user edited fields are String properties Validation should just validate that fields have the proper format Validation in the Struts Action should call business logic Form objects can contain Business Objects

108. Business Object A Business object is a Javabean (POJO) There should be a business object for each entity in the application Business objects can be used in any tier of the application In most cases, Business objects will be OJB data objects

109. Isolation Each tier should be isolated from other tiers A tier shouldn’t have knowledge of how a different tier is implemented A tier should only communicate to another tier through a Java interface The Spring framework can handle dependencies so each tier is truly isolated

110. Dependency Injection Spring will call set methods on managed objects so other objects don’t need to know details about how a dependant object works The dependencies are built into Spring’s context.xml file

111. Declarative Transactions Spring will manage transactions if they are defined in the context.xml No code is required to begin, rollback or commit a transaction No code is required to open and close database connections Spring handles this automatically No code means you can’t forget it!

112. Declarative Transactions Each method call into a service object is a transaction Spring automatically begins the transaction before the method call and ends it after If the method throws a runtime exception, Spring rolls back the transaction

113. Exceptions Runtime Exceptions  Use when situation is non-recoverable Checked Exceptions  Use when situation is recoverable Best Practice - fail as soon as possible  The closer the failure to the problem, the easier it is to find the problem Best Practice - fail big  Hidden failures make it more difficult to fix the problem