유닛 테스트 easymock으로

Question

그래서 단위 테스트를 수행하려는 벨로우 (bellow) 방법이 있습니다.

public List<Project> getProjects(Task task) { 

    Criteria<Project> criteria = this.myRepository.getCriteria(Project.class); 
    criteria.add(Comparison.eq("order", task.getOrder())); 
    criteria.addOrder(Order.asc("projectNumber")); 
    return this.myRepository.findList(Project.class, criteria); 
} 

그래서 실제로는 작업 개체를 가져옵니다 (그것은 JPA 모델 객체이다) 프로젝트 테이블을 던져가는이 프로젝트의 명령이있는 모든 프로젝트를 찾습니다. 두 테이블 모두에서 주문이 일반적입니다.

어쨌든, 쿼리 자체는 그 imp가 아닙니다. 그것은 db를 쿼리하고 일부 데이터를 반환합니다. 이제 내 문제는 내가 easymock으로 이것에 대한 단위 테스트를 수행 할 수 있습니까?

@Test 
public void testGetProjects() throws Exception { 
    myRepository = new CreateMyRepositoryWrapper(); --> This is a class which just returns the entityManger. but here we can consider this as a pojo. 

    Task task = EasyMock.createNiceMock(Task.class); 
    Order bom = EasyMock.createNiceMock(Order.class);   
    Project project= EasyMock.createNiceMock(Project.class); 

    project.setProjectName("project"); ------> Can I call a seeter on a mocked object? 

    project.setProjectNumber("1"); 

    EasyMock.replay(project); 

    List projects= new ArrayList(Arrays.asList(project)); 
    bom.setProjects(projects); ------------> Does it make sense to do this? 

    EasyMock.expect(task.getOrders()).andReturn(bom); 
    TestClass instance = new TestClass(); 
    instance.setMyRepository(myRepository); 

    EasyMock.replay(task,bom); 
    instance.getProjects(task); 

} 

따라서 테스트 사례를 통과합니다. 그러나 모든 사람들이 내가 실제로 테스트하고있는 것을 조롱하는 것은 확실하지 않습니다. 단지 그 메소드가 호출되고 있음을 보여주기 때문입니다. 하지만 그들이 assockEquals를 사용할 수 있는지 잘 모르고 있기 때문에 예외적 인 문제가 발생하더라도 위의 코드를 추가해야합니다.

그럼 내 질문 : 방법에 대해 적절한 단위 테스트 케이스가 있어야한다고 언급 했습니까?

감사합니다.

Answer 1

나는 당신이 거꾸로 조롱한다고 생각합니다. Mock myRepostory를 모방 한 다음 myRepository mock을 설정하여 Criteria 객체를 반환하고 Criteria 객체가 findList에 전달 될 때 프로젝트 목록을 반환합니다.

작업, 주문 및 프로젝트가 인스턴스화 될 수 있습니다.

이제 instance.getProjects (task)가 무언가를 반환합니다. 반환 된 항목이 findList에서 반환해야하는 것과 동일한 지 확인하기 위해 확인할 수 있습니다. 이제는 특별히 흥미로운 것은 아니지만 실제로 뭔가를 테스트했습니다.

기준 개체가 findList에 전달되기 전에 올바르게 설정되었는지 확인하고 싶을 수 있습니다. 그렇게하기 위해서는 기준을 모의로 만들어야하며, 그러면 어떤 메소드가 호출되는지에 대한 기대치를 설정할 수 있습니다. 여기서 까다로운 부분은 Hibernate Restriction 클래스는 기본이 아닌 equals 구현을 가지지 않기 때문에, 당신이 기대하는 제약 조건과 동일한 (기능적으로) 제약 조건에 전달되는 제약 사항을 확인하기 위해 자신의 정규 표현식을 작성해야한다.

또 다른 가능성은 실제 Criteria 객체로 기준을 설정하는 것입니다. (그런 다음 myRepository mock을 반환하여 반환 할 수 있습니다.) 그런 다음 함수가 호출 된 후 toString() 메서드 나 Criteria 객체를 조사하는 다른 방법으로 일치하는 부분 문자열을 사용하여 내용을 확인할 수 있습니다.

최종 (단위 테스트) 가능성은 Criteria 객체에 대한 조롱 프레임 워크를 사용하지 않는 것이지만 사용자가 직접 작성한 일부 코딩 된 프레임 워크를 사용하면 추가 된 모든 제한 사항을 검사 할 수 있습니다.

이 모든 것이 실제로 통합 테스트로 테스트되는이 방법에 대한 좋은 예입니다. 매우 흥미로운 것들을 확인하기 위해 많은 작업을 수행하고 코드를 리팩터링하려고하면 테스트가 매우 약해질 수 있습니다. (나는 그것을 직접했기 때문에 경험으로 말합니다.)