Using mockito in java
来源:互联网 发布:淘宝联盟安卓 编辑:程序博客网 时间:2024/06/07 20:08
If you’ve spent any time writing unit tests then you’ll know that it’s not always straight-forward. Certain things are inherently hard to test. In this post I’ll show you the basic principles of creating mock objects with a little help from the Mockito mocking tool.
One common problem faced when unit testing is how to test one object when it is dependant on another object. You could create instances of both the object under test and the dependent object and test them both together, however testing aggregated objects is not what unit testing is about – unit tests should test individual objects for their correct behaviour, not aggregations of objects! Moreover, this approach just won’t work if the dependent object hasn’t even been implemented yet.
A common technique for handling dependencies in unit tests is to provide a surrogate, or “mock” object, for the dependent object instead of a real one. The mock object will implement a simplified version of the real objects methods that return predictable results and can be used for testing purposes.
The drawback of this approach is that in a complex application, you could find yourself creating a lot of mock objects. This is where frameworks like Mockito can save you a lot of time and effort.
A Test Scenario
To demonstrate what you can do with Mockito, we’ll examine how we might test an Account object that is dependant on a data access object (AccountDAO). The account object can calculate the charges applicable in the current month by using the DAO to count the number of days overdrawn and then performing a simple calculation on the value obtained from that call. The method names on the classes we’ll use are self-explanatory:
AccountAndDAO
To test this thoroughly, we should test two things:
1. that the account obtains the number of overdrawn days by calling the correct method on the DAO,
2. that the account calculates the correct fees based upon the value it gets back from the call.
Testing that the account calls the correct method on the DAO
Using JUnit to run the test case, we could write something like this:
01.import static org.mockito.Mockito.*;
02.
03.public class TestAccount {
04.@Test
05.public void checkAccountCallsDaoMethods() {
06.//create the object under test
07.Account account = new Account();
08.
09.//create a mock DAO
10.AccountDAO mockedDao = mock(AccountDAO.class);
11.
12.//associate the mocked DAO with the object under test
13.account.setDAO(dao);
14.
15.//call the method under test
16.long charge = account.calculateCharges();
17.
18.//verify that the 'countOverdrawnDaysThisMonth' was called
19.verify(mockedDao).countOverdrawnDaysThisMonth();
20.}
21.}
Taking centre stage in all this is the Mockito class which has a bunch of static methods that are used within the unit test (note the static import on line 1).
The call to the ‘mock’ method (line 10) creates a mock object that can be used in place of a real AccountDAO. The call to ‘verify’ (line 19), will throw an exception if the ‘countOverdrawnDaysThisMonth’ method was not called on the mock object.
It is worth noting here that this is a simple example which just demonstrates the basic principle of verification, it is also possible to use the verify method to check for parameter values and ranges in the method call too.
Testing that the account performs its calculations correctly
In the above example, we mocked the DAO but didn’t specify what any of the mocked methods should do. In this case, all methods will return sensible default values of: null, zero or false. More commonly we need to specify something other than these defaults when writing our tests:
01.import static org.mockito.Mockito.*;
02.import static junit.framework.Assert.*;
03.import org.junit.*;
04.
05.public class TestAccount {
06.private Account account;
07.
08.@Before
09.public void setup() {
10.AccountDAO mockedDao = mock(AccountDAO.class);
11.
12.//specify that this method on the mock object should return 8
13.when(mockedDao.countOverdrawnDaysThisMonth()).thenReturn(8);
14.
15.account = new Account();
16.account.setDAO(dao);
17.}
18.
19.@Test
20.public void checkChargesWhenOverdrawn() {
21.//call the method under test
22.long charge = account.calculateCharges();
23.
24.//assert that the charge was £2 per day overdrawn
25.assertEquals(charge, 16);
26.}
27.}
The statement on line 18 specifies that whenever the ‘countOverdrawnDaysThisMonth’ is called it should return a value of 8; overriding the default of zero.
Given that the correct charge is two pounds (or dollars) per day overdrawn, then the assertion on line 25 will pass if the account performed the correct calculation (8 x 2 = 16 right).
Comments
There’s loads more to Mockito than we’ve looked at here. It’s a neat testing tool that works great with JUnit or TestNG. I’ve found that it’s small enough to learn quickly and capable enough to be really useful. Give it a go and write a comment below to let me know what you think of it
One common problem faced when unit testing is how to test one object when it is dependant on another object. You could create instances of both the object under test and the dependent object and test them both together, however testing aggregated objects is not what unit testing is about – unit tests should test individual objects for their correct behaviour, not aggregations of objects! Moreover, this approach just won’t work if the dependent object hasn’t even been implemented yet.
A common technique for handling dependencies in unit tests is to provide a surrogate, or “mock” object, for the dependent object instead of a real one. The mock object will implement a simplified version of the real objects methods that return predictable results and can be used for testing purposes.
The drawback of this approach is that in a complex application, you could find yourself creating a lot of mock objects. This is where frameworks like Mockito can save you a lot of time and effort.
A Test Scenario
To demonstrate what you can do with Mockito, we’ll examine how we might test an Account object that is dependant on a data access object (AccountDAO). The account object can calculate the charges applicable in the current month by using the DAO to count the number of days overdrawn and then performing a simple calculation on the value obtained from that call. The method names on the classes we’ll use are self-explanatory:
AccountAndDAO
To test this thoroughly, we should test two things:
1. that the account obtains the number of overdrawn days by calling the correct method on the DAO,
2. that the account calculates the correct fees based upon the value it gets back from the call.
Testing that the account calls the correct method on the DAO
Using JUnit to run the test case, we could write something like this:
01.import static org.mockito.Mockito.*;
02.
03.public class TestAccount {
04.@Test
05.public void checkAccountCallsDaoMethods() {
06.//create the object under test
07.Account account = new Account();
08.
09.//create a mock DAO
10.AccountDAO mockedDao = mock(AccountDAO.class);
11.
12.//associate the mocked DAO with the object under test
13.account.setDAO(dao);
14.
15.//call the method under test
16.long charge = account.calculateCharges();
17.
18.//verify that the 'countOverdrawnDaysThisMonth' was called
19.verify(mockedDao).countOverdrawnDaysThisMonth();
20.}
21.}
Taking centre stage in all this is the Mockito class which has a bunch of static methods that are used within the unit test (note the static import on line 1).
The call to the ‘mock’ method (line 10) creates a mock object that can be used in place of a real AccountDAO. The call to ‘verify’ (line 19), will throw an exception if the ‘countOverdrawnDaysThisMonth’ method was not called on the mock object.
It is worth noting here that this is a simple example which just demonstrates the basic principle of verification, it is also possible to use the verify method to check for parameter values and ranges in the method call too.
Testing that the account performs its calculations correctly
In the above example, we mocked the DAO but didn’t specify what any of the mocked methods should do. In this case, all methods will return sensible default values of: null, zero or false. More commonly we need to specify something other than these defaults when writing our tests:
01.import static org.mockito.Mockito.*;
02.import static junit.framework.Assert.*;
03.import org.junit.*;
04.
05.public class TestAccount {
06.private Account account;
07.
08.@Before
09.public void setup() {
10.AccountDAO mockedDao = mock(AccountDAO.class);
11.
12.//specify that this method on the mock object should return 8
13.when(mockedDao.countOverdrawnDaysThisMonth()).thenReturn(8);
14.
15.account = new Account();
16.account.setDAO(dao);
17.}
18.
19.@Test
20.public void checkChargesWhenOverdrawn() {
21.//call the method under test
22.long charge = account.calculateCharges();
23.
24.//assert that the charge was £2 per day overdrawn
25.assertEquals(charge, 16);
26.}
27.}
The statement on line 18 specifies that whenever the ‘countOverdrawnDaysThisMonth’ is called it should return a value of 8; overriding the default of zero.
Given that the correct charge is two pounds (or dollars) per day overdrawn, then the assertion on line 25 will pass if the account performed the correct calculation (8 x 2 = 16 right).
Comments
There’s loads more to Mockito than we’ve looked at here. It’s a neat testing tool that works great with JUnit or TestNG. I’ve found that it’s small enough to learn quickly and capable enough to be really useful. Give it a go and write a comment below to let me know what you think of it
- Using mockito in java
- Using Mockito to Unit Test Java Applications
- Using REST in Java
- Using scrolls in java
- Use Mockito in Junit
- Using Sockets in Java - Client
- Using Sockets in Java - Server
- using mysql in java application
- Java mock工具-mockito
- Java测试包Mockito
- Mockito java doc
- java mock-Mockito
- Methods for Using Java in ORACLE(转荐)
- Using Java Web Start in NetBeans IDE
- Single Sign-on Using Kerberos in Java
- Using Collections.sort and Comparator in Java
- Using Collections.sort and Comparator in Java
- Single Sign-on Using Kerberos in Java
- 用核心交换机实现三层交换
- lighttp 配制文件
- S3C2440 进行微秒级、毫秒级延时函数
- JSON学习笔记
- 实现TreeView单选框CheckBox单选
- Using mockito in java
- 分享8年开发经验,浅谈个人发展经历,明确自己发展方向
- JasperReport+iReport进行Web报表开发
- 利用JDBC操作Oracle CLOB和BLOB类型数据
- QTP学习笔记之2.2 --Object Repository相关示例代码
- 配置 Office SharePoint Server 2007
- Xen 内存与CPU分配 常用命令
- 谈谈数据库开发的分层
- S3C2410的ADC和触摸屏接口的5种工作模式