어젯밤 AgileChina 2011 오픈 하우스 행사가 있었는데, 저는 코딩 세션에 자원 봉사자로 참여했습니다. 코딩 세션의 주요 목적은 참여하는 개발자들이 페어 프로그래밍, 테스트 중심 개발 및 리팩토링 프로세스를 경험하도록 하는 것입니다. 우리는 8~9명의 회사 동료와 참여 동료가 이 과정을 함께 경험하게 될 네 가지 유형의 프로그래밍 질문을 준비했습니다. 소스 코드 라인
블랙잭 게임
두 가지 작은 에피소드를 제외하면 전반적으로 이벤트는 꽤 성공적이었습니다.
1. 회사에서 원하는 대로 새 키보드와 마우스를 구입했습니다. , 하지만 입력할 때 촉감이 너무 좋고 키보드의 키가 평평합니다. 한 참가자는 키보드에 익숙하지 않아 항상 실수로 슬래시를 여러 번 입력할 수 있습니다.
2. 시스템의 잠금 화면 단축키가 IDE의 서식 코드 단축키와 충돌하여 잘못된 키를 두 번 입력하여 화면이 잠겼습니다. 비밀번호 입력을 도와줄 다른 동료를 찾으려고요.
페어의 마지막 라운드에서 한 학생이 다음과 같이 질문했습니다. 왜 AssertEquals를 사용하지 않습니까? 나는 여러분 모두가 AssertThat을 사용하고 있다는 것을 알았고, AssertEquals, AssertTrue 등의 사용은 그다지 권장되지 않는 것 같습니다.
행사가 거의 끝나가서 단체 사진을 찍으려고 했기 때문에 간단하게 답변을 드렸습니다. 이 질문에 대한 자세한 답변은 다음과 같습니다.
어설션에서 무엇을 얻고자 합니까
테스트의 어설션에서 무엇을 얻고 싶습니까? 테스트가 실패한 후에 빨간색 막대를 표시하는 것도 우리가 원하는 것이 아닙니다.
1. 테스트가 실패한 줄이 있습니까? 모든 어설션은 이 기능을 제공할 수 있습니다
2. 테스트가 실패한 이유를 정의하기는 어렵습니다. 대부분의 어설션은 유사한 기능을 제공할 수 있습니다.
원하는 결과와 실제 결과
그러나 서로 다른 어설션은 서로 다른 정보를 제공합니다. 동등성과 같은 간단한 주장을 사용하여 비교하기 어려운 문제도 있습니다. 게다가 어설션은 문서화라는 매우 중요한 역할도 합니다. 즉, 테스트 코드를 읽을 때 모든 기대치를 보는 것처럼 어설션을 보게 됩니다. 그리고 매우 명확한 기대.
실제 예
assertThat의 두 번째 매개변수를 살펴보세요. 이는 Matcher
여기에 문제가 있습니다. 위의 두 주장이 모두 실패하면 첫 번째 주장의 실패 메시지는 다음과 같습니다.
1: assertThat(userDAO.findAll(), hasItem(expected));
1: assertTrue(userDAO.findAll().contains(expected));
그리고 두 번째 주장은 어떻습니까? 이렇습니다.
사실이라고 예상한 것, 실제로는 거짓
어느 쪽이 더 믿을만한가요? 분명히 첫 번째 주장의 실패 정보는 문제를 찾는 데 더 도움이 됩니다.
문서화를 위해 다음 요구 사항을 살펴보겠습니다. 반환된 사용자 목록에 지정된 사용자가 포함되어 있지 않은지 확인:
이 내용이 매우 명확하지 않습니까? 주장 Spec을 읽는 것처럼 코드를 읽는 것처럼 느낄 것입니다. 다른 주장이 사용되는 경우:은 이전 주장만큼 잘 문서화되어 있지 않습니다.
1: assertThat(userDAO.findAll(), not(hasItem(expected));
1: assertFalse(userDAO.findAll().contains(expected));
그래도 실수를 하시나요?
1: assertEquals(userDAO.findBy(id), expected);
1: assertThat(userDAO.findBy(id), is(expected));