엔티티 계층에서 다양한 객체의 생성, 삭제 등을 조정하는 서비스 계층을 호출하는 REST 웹 서비스 인터페이스가 있습니다. 이러한 엔티티 계층 개체는 궁극적으로 데이터베이스 레코드에 매핑됩니다. 나는 http 요청을 보내서이 인터페이스를 테스트하는 단위 테스트 (nunit, C# 응용 프로그램)를 가지고있다.유닛 테스트에서 코드 재사용
일부 엔티티 계층 개체를 만드는 웹 서비스 요청 테스트를 고려해보십시오. 분명히 웹 서비스가 요청을 올바르게 처리했는지, 응답 상태 인 http 상태 및 응답 본문의 일부 데이터를 검사하여 웹 서비스가 해당 프로세스를 제대로 처리하는지 확인하려고합니다. 또한 올바른 데이터베이스 레코드가 작성되었는지 독립적으로 검증하려고합니다.
가장 쉬운 방법은 데이터베이스 항목을 읽고 유효성을 검사하는 엔티티 층에 존재하는 '독자'클래스를 사용하는 것입니다 : 나는이 작업을 수행하는 몇 가지 방법을 (내가 생각할 수 있음)이있다. 이는 그들이 처리하는 엔터티에 대한 유효성 검사 및 일관성 논리를 통합하고 사용하기가 쉽기 때문에 쉽습니다. 내가이 코드를 부분으로 테스트로 사용하고 있기 때문에 나는 이것에 대해 불안하다. 이것은 관심사 분리의 원칙을 위반하는 것으로 보이며 객체 생성을 실패하게하는 엔티티 계층 버그가 발생할 가능성을 소개하지만 성공하려면 유닛 테스트에 나타납니다.
또는 테스트 코드는 데이터베이스로 곧바로 이동하여 자체 검사를 수행 할 수 있습니다. 그런데 테스트에서 객체 저장 및 일관성 규칙에 대한 세부 정보를 포함하고 있습니다. 세부 사항이 변경되면 테스트가 취약 해지며 단위 테스트에서 엔티티에 이미 작성한 코드를 다시 구현한다는 것을 의미합니다. 층.
사람들은 이러한 (그리고 다른 옵션) 옵션과 관련된 절충안에 대해 어떻게 생각하는지 궁금하고 궁금한 사항이 있다면 무엇입니까? 나는 옳고 그른 대답이 있는지 확실하지 않지만 잠시 동안 그것에 대해 궁금해하고 다른 의견에 관심이 있습니다.
명확히 편집, 내가 서비스 레이어와 개체 계층에 대해 별도의 테스트 스위트를 저장합니다. 테스트에서 테스트 코드를 사용하여 표현한 우려는 이러한 테스트에도 적용됩니다.
응답 해 주셔서 감사합니다. 엔티티 레이어와 서비스 레이어에 대해 별도의 테스트 슈트가 있다는 내용의 질문을 편집했습니다. 이것은이 레이어가 독립적으로 작동한다는 확신을 주지만 테스트에서 코드의 사용은 궁극적으로 (심지어 두 개의 레이어가 아래에 있더라도) 테스트의 일부분 인 코드를 사용하는 것에 대해 여전히 불안합니다. 너 뭐하니? –
@Andy 잘 독자 테스트가 적합하다고 생각하거나 그렇지 않습니다. 그렇지 않으면 다시 작성하십시오. 그렇게 할 경우 사용하십시오. 다른 방법으로는 독자가 테스트 코드로 다시 작성하더라도 테스트에 대한 테스트를 작성하지 않으면 올바른지를 모를 것입니다.) – Max
나는 단위 테스트와 통합 테스트를 이미 구분했으며,이 특정 경우 웹 서비스 및 서비스 계층 테스트를 통합 테스트로 분류합니다. 나는 아마도 그러한 테스트에서 엔티티 레이어 코드를 다시 사용할 수 있다는 것에 동의합니다. 그래서 당신의 대답을 받아 들였습니다. 이 문제에 대한 내 생각을 분명히하도록 도와 주셔서 감사합니다. –