单元测试在现代软件开发中变得越来越重要,我发现自己迷失了方向。我主要是Java程序员,我理解单元测试的基础知识:有适当的方法来测试应用程序中的基本操作。我可以为简单(通常用作示例)案例实现这一点:
public boolean addNumbers(int a, intb) {return a + b;}
//Unit test for above
public boolean testAddNumbers() {return addNumbers(5, 10) == 15;}
令我困惑的是如何将其转化为实际应用。毕竟,大多数简单的函数已经在API或JDK中。我在工作中经常做的真实情况是数据访问,即编写DAO以使用数据库。我不能像上面的例子那样编写静态测试,因为从Oracle框中提取记录集可以返回一整套事物。编写仅在返回集中查找特定模式的通用单元测试似乎过于宽泛且无益。相反,我没有写单元测试。这很糟糕。
我不知道如何处理写入测试的另一个例子是Web应用程序。我的Web应用程序通常构建在J2EE堆栈上,但它们并不涉及太多逻辑。通常,它从数据库传递信息,几乎没有操作。这些单元测试的目标是否合适?
简而言之,我发现绝大多数单元测试示例都集中在过于简单且与我的工作无关的测试用例上。我正在寻找任何(最好是Java)关于为移动和显示数据而不是在其上执行逻辑的应用程序编写单元测试的示例/技巧。
答案 0 :(得分:2)
您通常不会为DAO编写单元测试,而是进行集成测试。这些测试基本上包括
无耻插件:DbSetup是第一部分的好工具。但是存在像DBUnit这样的其他工具。
要测试应用程序的业务逻辑(复杂与否,并没有太大变化),您通常使用像Mockito这样的模拟框架来模拟DAO:
SomeDao mockDao = mock(SomeDao.class);
when(mockDao.findAllEmployees()).thenReturn(Arrays.asList(e1, e2, e3));
SomeService service = new SomeService(mockDao);
someService.increaseSalaryOfAllEmployeees(1000);
// todo verify that e1, e2 and e3's salary is 1000 larger than before