Abstract 클래스와 N 확장으로 구성된 Java 클래스 계층 구조가 있습니다. 추상 클래스에는 @Remove 주석으로 주석이 달린 메소드가 있습니다. 이 주석이 제거되면 예외가 빨리 발생하지는 않지만 메모리 예외가 발생할 수 있으므로 일부 리팩토링에서 주석이 사라지면 가능한 한 빨리 통지하고 싶습니다.
GUTS (좋은 단위 테스트)를 만들려고 노력하고 있으므로 테스트에서이 “기술 요구 사항”을 설명하는 테스트 사례와 함께 문서화 할 수 있다고 생각했습니다.
그러나 이것은 기능이 아니며 구현 세부 사항이며 메서드의 동작과 관련이 없습니다 (메소드는 비어있을 수 있지만 존재해야하며 주석이 있어야합니다).
테스트를 작성해도 괜찮습니까? 아니면이 주석이 있는지 확인하는 다른 방법이 있습니까?
답변
예, 단위 테스트를 작성하십시오. 주석이 제거되면 프로덕션에서 메모리 버그를 벗어날 수 있습니다. 그것은 킬러 버그 일 것입니다. 테스트가 어떻게 든 제한되어야한다는 아이디어 때문에 이런 일이 일어나게하는 것은 반 생산적입니다. 테스트는 모든 의미에서 정확성을 확인해야합니다. 가능한 문제를 빨리 발견할수록 단위 테스트를 수행하고 CI 빌드에 실패하면 버그를 예방할 수있는 확실한 방법입니다. 그러한 버그의 도입을 막기 위해 다른 메커니즘을 발명하려고 시도하는 것은 가치가 없어 보입니다. 모든 새로운 개발자에게는 기능적 정확성 테스트가없는 “특별한 경우”를 처리하는 방법에 대한 설명이 제공되어야합니다. 개발자 시간을 잘 사용하지 않는 것 같습니다.
BDD를 수행하는 편집 팀은 비즈니스 기능 테스트와 성능 테스트와 같은 기술 테스트를 분리 할 수 있습니다. 일반적으로 팀에는 핵심 비즈니스 로직 테스트보다 덜 자주 실행되는 통합 테스트를 포함하여 다양한 유형의 테스트가 있습니다. 일반적으로 빌드 프로파일을 사용하여 플로우의 개발자가 빠른 비즈니스 로직 테스트를 자주 수행하고 코드를 커밋하기 전에 느린 통합 테스트를 실행할 수 있습니다. CI 빌드는 모든 테스트를 실행합니다.
답변
이와 같은 선언적 기술을 사용하여 중요한 함수를 구현할 때는 선언을 인식하는 프레임 워크의 일부를 포함하는 통합 테스트를 사용하는 것이 좋습니다. 이를 통해 프레임 워크 동작의 변경, 선언의 효과에 대한 오해 등을 방지 할 수 있습니다. 주석의 존재를 테스트한다고해서 특정 행동이 보장되는 것은 아닙니다.