단위 테스트에서 주석의 존재를 확인할 수 있습니까?


9

Abstract 클래스와 N 확장으로 구성된 Java 클래스 계층 구조가 있습니다. 추상 클래스에는 @Remove 주석으로 주석이 달린 메소드가 있습니다. 이 주석이 제거되면 예외가 빨리 발생하지는 않지만 메모리 예외가 발생할 수 있으므로 일부 리팩토링에서 주석이 사라지면 가능한 한 빨리 통지하고 싶습니다.

GUTS (좋은 단위 테스트)를 만들려고 노력하고 있으므로 테스트에서이 "기술 요구 사항"을 설명하는 테스트 사례와 함께 문서화 할 수 있다고 생각했습니다.

그러나 이것은 기능이 아니며 구현 세부 사항이며 메서드의 동작과 관련이 없습니다 (메소드는 비어있을 수 있지만 존재해야하며 주석이 있어야합니다).

테스트를 작성해도 괜찮습니까? 아니면이 주석이 있는지 확인하는 다른 방법이 있습니까?


1
어떻게해야하는지, 아니면 소프트웨어 엔지니어링이 좋은지 물어보고 있습니까? 후자의 대답은 '그렇다'입니다. 테스트는 코드베이스의 품질을 검증합니다. 반드시 현재의 행동을 점검 할 필요는 없습니다 . 미래의 좋은 행동 을 장려하기위한 조건을 검증하는 테스트를하는 것은 완벽합니다 .
Kilian Foth

답변:


5

예, 단위 테스트를 작성하십시오. 주석이 제거되면 프로덕션에서 메모리 버그를 벗어날 수 있습니다. 그것은 킬러 버그 일 것입니다. 테스트가 어떻게 든 제한되어야한다는 아이디어 때문에 이런 일이 일어나게하는 것은 반 생산적입니다. 테스트는 모든 의미에서 정확성을 확인해야합니다. 가능한 문제를 빨리 발견할수록 단위 테스트를 수행하고 CI 빌드에 실패하면 버그를 예방할 수있는 확실한 방법입니다. 그러한 버그의 도입을 막기 위해 다른 메커니즘을 발명하려고 시도하는 것은 가치가 없어 보입니다. 모든 새로운 개발자에게는 기능적 정확성 테스트가없는 "특별한 경우"를 처리하는 방법에 대한 설명이 제공되어야합니다. 개발자 시간을 잘 사용하지 않는 것 같습니다.

BDD를 수행하는 편집 팀은 비즈니스 기능 테스트와 성능 테스트와 같은 기술 테스트를 분리 할 수 ​​있습니다. 일반적으로 팀에는 핵심 비즈니스 로직 테스트보다 덜 자주 실행되는 통합 테스트를 포함하여 다양한 유형의 테스트가 있습니다. 일반적으로 빌드 프로파일을 사용하여 플로우의 개발자가 빠른 비즈니스 로직 테스트를 자주 수행하고 코드를 커밋하기 전에 느린 통합 테스트를 실행할 수 있습니다. CI 빌드는 모든 테스트를 실행합니다.


2

이와 같은 선언적 기술을 사용하여 중요한 함수를 구현할 때는 선언을 인식하는 프레임 워크의 일부를 포함하는 통합 테스트를 사용하는 것이 좋습니다. 이를 통해 프레임 워크 동작의 변경, 선언의 효과에 대한 오해 등을 방지 할 수 있습니다. 주석의 존재를 테스트한다고해서 특정 행동이 보장되는 것은 아닙니다.


안녕! 예를 들어 @remove 주석의 동작을 어떻게 확인 하시겠습니까?
JSBach

불행히도, 나는 이것에 대답하기에 EJB에 익숙하지 않습니다. 좋은 테스트를 작성하기가 어렵 기 때문에 기술로 정확하게 작업하지 않는 경향이 있습니다.
Jules

이 주석의 아이디어는 컨테이너에 Bean을 제거 할 수 있음을 알리는 것입니다. 불행히도이 동작을 테스트하는 것은 어렵습니다 :(
JSBach
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.