테스트 클래스명 을 강의처럼 만드신 이유가 따로 있을까요?

아주 특별한 이유는 없습니다. Test 접미어를 사용하는 경우도 있지만 큰 의미를 두지는 않고 강의에서는 specs라는 접미어가 테스트가 소프트웨어 명세라는 것을 강조하는 효과가 있기는 합니다. 그리고 제가 말씀하신 기능을 사용하지 않기 때문에 Test 접미어에 더 의미를 두지 않는 것 같기도 하네요.다른 얘기지만 {운영 클래스 이름}Test 명명법에 큰 의미를 두는 분들이 package-private 클래스까지 테스트를 작성하려는 실수를 저지르는 사례는 많이 봤습니다.

현업에서도 현재와 같은 방식? 으로 TDD를 하는것이 일반적인가요??

다익스트라님 안녕하세요. 강의 수강해 주시고 질문도 남겨 주셔서 정말 고맙습니다. 🙂저는 말씀하신 것처럼 요구사항 충족을 가장 중요하게 생각합니다. 하지만 아키텍처가 중요하지 않다는 뜻은 아닙니다. 다만 저는 고수준 아키텍처와 공개된 모듈 간 인터페이스는 가능한 상세하게 설계하지만 그 내부의 아키텍처는 미리 설계하거나 에너지를 많이 쏟지 않습니다.그러면 어느 수준에서 공개된 모듈을 정의할 것인가가 남게되는데 이건 각 프로젝트 상황에 따라 많이 달라지며 저는 분명한 필요가 없다면 공개(public) 모듈을 가급적 만들지 않습니다. 그렇게 해야 설계가 유연하게 관리되고 변경 비용이 감소하기 때문입니다.

아키텍처와 TDD의 오해에 대해 질문드립니다.

민우님 안녕하세요. 강의 수강해 주셔서 고맙습니다. 질문에 답변 드리겠습니다. 🙂레이어드 아키텍처 사용저는 응용프로그램의 규모와 복잡도에 따라 아키텍처를 선택하는 편입니다. 그리고 테스트 대상 표면 내부의 설계에 대해서는 크게 신경쓰지 않습니다. 강의에서는 테스트 대상 표면으로 HTTP API를 사용했기 때문에 그 내부에서 어떤 아키텍처를 사용하는지는 그리 중요하지 않았습니다. 규모가 조금 큰 HTTP API 앱을 설계할 때는 컨트롤러와 그 외 부분을 분리해서 설계하긴합니다.하지만 이 때도 '그 외 부분'의 내부에 대해서는 설계에 많인 비용을 들이지 않습니다. 특히 'Service' 접두어는 안티 패턴으로 규정하고 사용하지 않습니다. 'Service' 접두어를 사용하는 클래스는 덩치가 커지고 의존성이 복잡해지는 경향이 있기 때문입니다. 대신 '...CommandHandler', '...QueryHandler' 처럼 역할을 명확하게 규정한 작고 단순한 코드를 만듭니다.'TDD를 잘하려면 인터페이스를 많이 사용해야 한다'는 주장의 배경무비판적이고 기계적인 정보(DI, DIP, 헥사고날 아키텍처, ...) 수집의 병폐가 아닐까 싶습니다. 각 기법의 의미와 장단점을 이해하고 목적에 맞게 선별해서 사용하는 것이 아니라 어떤 이론에 나와있으니까 등의 이유로 특히 Java 생태계에서 많이 퍼진 것 같습니다.그리고 Mockist 테스팅(지금은 안티 패턴으로 알려진)의 유행도 큰 영향을 미친 것 같습니다.https://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting복잡한 비즈니스 논리 오류 추적TDD를 하면 전체 코드는 복잡하더라도 모든 테스트를 통과하는 코드베이스에 조금씩 점진적으로 코드를 늘려갑니다. 그렇기 때문에 테스트가 실패하면 원인은 방금 만들어진 작은 변경 내에 있을 가능성이 높습니다. 그래서 문제를 찾는 것이 보통 어렵지 않습니다.TDD를 하지 않는다면 상황이 조금 다를 수는 있지만, 그래도 테스트가 있는 상황이라면 문제를 쉽게 재현할 수 있고 디버깅 하기 쉽기 때문에 문제 원인 분석이 그렇게 어렵지는 않습니다.그래서 저는 실패하는 테스트 때문에 테스트를 추가한 경험은 없는 것 같습니다.답변이 부족했다면 말씀해 주세요!

임의데이터 generator방식과 @Transactional에 대한 고찰

저는 테스트를 위해서 @Transactional 애노테이션을 사용하거나 필요하다는 생각을 해본적이 없지만 상황에 따라서는 효율적인 방법일 수 있습니다.다만 제가 @Transactional 애노테이션 쓸 생각을 하지 않는 이유를 (굳이) 떠올려 보자면 이런 것들이 있을 것 같습니다.테스트 환경의 장치가 운영 코드의 동작에 영향을 주는 것을 가급적 피하고 싶다.실제 비즈니스 논리는 빈 데이터베이스에서 실행되지 않는다.테스트 결과를 이해하기 어려울 때 디버깅하기 쉽다.@Transactional 애노테이션이 지원되지 않는 저장소(S3 등)를 사용하는 경우도 많다.답변이 부족했다면 말씀해주세요!

내부 설계에 의존하는 테스트 관련 질문 드립니다.

안녕하세요. 제가 이 질문 알림을 놓쳐서 답변이 조금 늦었습니다. 🙏우선 외부 설계와 내부 설계에 대해서 설명드리면 생각하시는 것처럼 어떤 코드 모듈 외부에서 인지할 수 있는 설계를 뜻하고 인터페이스를 통해 노출됩니다. 그리고 내부 설계는 인터페이스를 통해서 드러나지 않은 설계입니다. 정보 숨김(information hiding) 이란 기법에서 말하는 정보가 바로 이 내부 설계 결정(design decision)입니다. 일부 설계 결정을 내부에 숨김으로서 설계 이점을 취할 수 있습니다.내부 설계는 말 그대로 내부에 있기 때문에 외부에서 사용되지 않아야 설계 이점을 충분히 얻을 수 있습니다. 하지만 아주 가끔씩은 테스트가 이 내부 설계를 이해하고 사용해서 얻을 수 있는 이점이 더 크기도 합니다. 보안과 관련된 기능을 테스트 할 때나 기존 코드의 설계 품질이 낮을 때 종종 이런 상황이 발생합니다.엔지니어링은 적은 비용으로 많은 이점을 얻는 활동이기 때문에 이런 상황이 발생했을 때 원칙을 지킬지, 아니면 원칙을 깨고 테스트가 내부 설계에 의존하게 할지는 프로그래머 각자가 잘 판단해야 합니다.답변이 부족했다면 말씀해주세요!

테스트 시나리오 관련 질문 드립니다.

좋은 질문이지만 답변 드리기 어려운 질문입니다. 결론부터 말씀드리면 아직 알려진 명확한 순서 기준이 없습니다. 만약에 있는데 제가 알지 못한다면 저도 배우고 싶습니다.Kent Beck은 테스트 선택에 대해서 이렇게 얘기했습니다.Picking the next test is an important skill, & one that only comes with experience. The order of the tests can significantly affect both the experience of programming & the final result.다음 테스트를 선택하는 것은 중요한 기술이며, 경험이 쌓여야만 얻을 수 있는 능력입니다. 테스트의 순서는 프로그래밍 경험과 최종 결과 모두에 상당한 영향을 미칠 수 있습니다.경험이 쌓여야만 한다고 얘기했지만, 그래서 어떻게 하면 되는지 방법을 특정하지는 않습니다.그래도 제가 실무에서 사용하는 기준 몇 개를 말씀드려 보면비즈니스 프로세스의 성공적 서례(해피 패스)부터 선택비교적 자신이 있는 기능을 만들 때는 구현하기 쉬운(또는 그럴 것으로 예상되는) 것부터 선택자신이 충분하지 기능을 만들 때는 구현하기 어려운(또는 그럴 것으로 예상되는) 것부터 선택등 이 있는데요, 이런 것들은 어디에선가 배운 것이 아니고 긴시간 경험적으로 사용하게 된 것이고 1, 2, 3번 중 어떤 기준을 선택할 지도 새로운 기능을 만들 때 마다 경험적으로 선택합니다. 아직 저도 뚜렷한 원칙이 있지는 않습니다.명확하게 답변 드리지 못해서 죄송합니다.

@SpringBootTest 어노테이션의 classes 관련 질문 드립니다.

counterchord89 안녕하세요. 강의 수강해 주셔서 고맙습니다. :)@SpringBootTest 애노테이션은 대상 클래스의 패키지를 사용해서 스프링 구성 클래스를 탐색합니다. 그런데 강의에서는 테스트 클래스가 운영 코드와 다른 패키지에 정의됩니다.(강의에서 그 이유가 설명됩니다.) 그래서 @SpringBootTest 애노테이션이 자동으로 스프링 구성 클래스를 탐색하지 못하기 때문에 명시적으로 지정해준 거에요.혹시 답변이 충분하지 않으면 말씀해 주세요!

거짓 음성, 거짓 양성 관련 질문 드립니다.

맞습니다. 🙂"시스템에 문제가 있으나(코로나 감염) 테스트(코로나 검사)는 시스템에 문제가 없다라고 나왔으니(코로나 음성 결과) 거짓 음성"이라고 표현하면 조금 더 정확할 것 같습니다.또 궁금하신 것이 있으면 질문 주세요!

30. 누락된 테스트 시나리오 발견

승현님 안녕하세요. 강의 수강해주셔서 고맙습니다. 질문 주신 내용에 답변 드려보겠습니다. 첫번째로 email의 경우와 다르게 username의 경우에서만 테스트 시나리오를 추가한 이유는, email에 사용된 정규식은 알려져 있는 정규식을 가져와서 사용한 반면에 username에 사용한 정규식은 처음부터 필요한 만큼씩 구성해 나갔기 때문입니다. 그래서 전자의 경우에는 입력 검증에 부족함이 없을 거라고 예상할 수 있었지만 후자의 경우에는 그렇지 않아서 테스트 시나리오 보강이 필요하다고 판단했습니다. 두번째로 "올바르게 요청하면 204 반환"의 경우는 말씀하신 것처럼 해석할 수 있고 기존 테스트를 매개변수화 테스트로 변환하는 것을 고려할 수 있습니다. 이 사례 뿐만 아니라 다른 경우에서도 제가 강의에서 사용한 방식이 유일하게 올바른 방식은 아니며, 다른 더 나은 방법이 있을 수도 있습니다. 다만 저는 가급적이면 기존에 만들어진 테스트를 수정하지 않는 방식을 우선 고려합니다. 테스트 코드를 조금이라도 수정하게 되면 테스트에 대한 신뢰를 다시 쌓아야 하기 때문인데 테스트 신뢰에 대해서는 조금 더 수강하시면 다루게 될 거에요. :) 혹시 답변이 부족하다면 말씀해주세요!

69.테스트격리 / 과도한 테스트 격리의 문제 중 '부적절한 설계 왜곡'

백엔드해야지님 안녕하세요. 우선 강의 수강해주셔서 감사드립니다!말씀하신 부분의 제 의도를 정확히 이해하신 것으로 생각됩니다. 🙂1번에 대해서 조금 부가 설명을 드려보면, A 클래스에 코드가 늘어나서 일부 코드를 B 클래스로 분리하면 어떤 분들은 B 클래스에 대한 인터페이스를 만들어서 B 클래스를 주입하도록 하기도 합니다. 그러면 B 클래스는 A 클래스의 변형된 구현 설계임에도 public으로 노출되고 A 클래스의 관계가 복잡해 집니다.