Inversion of Control pattern for unit testing


J2EE patterns: Inversion of Control pattern for unit testing

  1. What is Inversion of Control? Inversion of control pattern is used for loose coupling between components. Components should program to an interface for services they require, this way the actual implementation can be changed at any time. The creation of the object of the actual implementation should not be hard coded in the components. The service consuming component doesn’t know anything about how to create the service providing component. It is the responsibility of the service configurator or the container to inject the dependencies based on some configuration. It is also called dependency injection because the container is creating the dependent objects and injecting them into the component. The dependency injection can be done using constructors or setters. You can either use your own service configurator or use a framework for IOC like spring, hivemind and picocontainer How can it be used for Unit Testing? Because the components are loosely coupled, a component can be tested without depending on other components. When creating an interface the programmer can also create a mock implementation of the interface. The component programmer can test his component by using the mock implementation during the testing, which can be later changed to the actual implementation. Even if you know that there won't be more than one implementation of a service it is still better to create an interface and use IOC, because of its use in Unit Testing.
  2. It sounds logical, but like to see an example to better understand … Any URL to examples?
  3. It sounds logical, but like to see an example to better understand … Any URL to examples?
    Check out the Spring Framework It's all about dependency injection.
  4. Webwork and Spring both provides implementation of iOC pattern sudhir nimavat
  5. We use this in a number of situations. In one case, we have a class (let's name it PeriodicCaller) whose job is to make requests to a database at various intervals. The intervals change based on the results of the previous database request. In order to test the component, we factored out the direct dependencies on the database and the system clock into injectable components. I.E., when you construct the PeriodicCaller, you pass in an instance of SystemClock and an instance of MyDatabase. The SystemClock interface contains the methods Sleep(x) and CurrentTime(). The MyDatabase interface contains model-level methods like GetRecordCount(), GetNextRecord(), and DeleteRecord(). The production SystemClock implementation delegates directly to Thread.sleep() and System.currentTimeMillis(). The production MyDatabase implementation wraps a JDBCPool and returns the results of SQL queries. Let's say that PeriodicCaller is supposed to call the database, process records (call Get and then Delete) until it is empty, and then sleep 1 minute before checking for new records. If an exception occurs, the PeriodicCaller should wait 30 seconds before calling again. How can we test this? (1) We create a mock implementation of SystemClock that wraps a "currentTime value". In the Sleep(x) method, increment the current time by x, then return. CurrentTime() returns the wrapped value. (2) We create a mock MyDatabase implementation that returns a certain number of records, then returns none, then returns some more, then throws an exception. Inside each call to the mock Database, before returning a record (or returning "count == 0"), we set an internal variable saying what time we expect the next call to be. When the next call comes in, we compare the stored "expected time" to the actual value of the mock SystemClock - if too much or too little time has passed, the test failed! There are more details to our actual implementation (think interrupts...), but you should get the idea.
  6. There are a number of tutorials dealing with build automation and IOC component management under the DPML site. The DPML Depot Tutorials cover the subject of build automation (including unit test automation), and the DPML Metro Tutorials goes into the subject of IOC management including unit test handling.