#통합테스트

테스트코드 작성 시 테스트더블 사용 vs 미사용 관련 질문이에요!

안녕하세요. 테스트코드에 관한 공부를 하게 되고 작성을 해보면서 의문이 들어서 질문을 드립니다. 테스트코드에 관한 얘기에서 항상 제목의 주제가 빠질 수 없는 것 같습니다. 둘 다 추구하는 바가 다를 뿐이지 틀리지 않았기 때문에 정답이 없다는 것은 알고 있지만 아직도 혼란스럽네요. 테스트코드에 관한 공부를 하면 항상 나오는게 유닛테스트, 통합테스트 등의 개념인데요. 도메인의 책임을 유닛테스트 하는 것까지는 쉽게 이해가 가는데 서비스 계층을 유닛 테스트 한다는 것이 조금은 이해(?), 수용(?)이 쉽지가 않네요. 서비스 로직은 필연적으로 외부 시스템에 의존할 수 밖에 없다고 생각을 하는데요.(DB, 외부 API 등등) 그러다보니 이런 것을 배제하고 Fake 객체나 Mockito 라이브러리 등을 사용해서 stubbing을 하고 테스트코드를 작성하는 것이 실제 운영 환경에서의 버그 혹은 문제 등을 올바르게 캐치하는 것이 가능한 것인가 하는 궁금증이 생깁니다. 외부 API는 매번 테스트코드를 돌릴 때마다 호출하는 것이 불가능할 수도 있으니 테스트더블을 사용하는 것이 크게 이상하다고 느껴지진 않습니다만, 저는 DB와 관련해서는 아직도 조금 혼란스러운 상황이네요. 실제로 테스트를 다 mocking 처리해서 작성을 해서 DB와 관련한 변경이 있을 때 테스트코드가 그걸 캐치 못 한 경험이 있는데 그 때 이럴거면 테스트코드 왜 짜지? 하는 의문이 들었던 적이 있습니다. 항상 유닛테스트가 중요하다고 다들 말씀하시는데 그러면 그 분들은 테스트코드를 작성하실 때 서비스 로직에서도 DB와 분리된 테스트더블을 사용하는 유닛 테스트를 작성하신다는 의미일까요? 아니면 테스트더블을 사용한 서비스 레이어 유닛 테스트 작성 + 테스트용 DB 혹은 h2 등을 사용하는 통합테스트 모두 다 작성해버리면 그만이니까 이런 고민을 하는게 의미가 없는 것인가? 하는 생각도 한편으로 드네요. 테스트코드를 작성하시는 다른 분들은 이 문제에 관해 어떻게 생각하시는지 궁금합니다 :D

안녕하세요 신입 개발자 최기환이라고 합니다! 테스트 코드 관련해서 선배님들의 고견을 여쭙고 싶습니다!

1. 로그인 폼에 대한 테스트를 작성하다 생긴 의문이 있습니다. 현재 테스트에 대해 공부하며 로그인 폼에 대한 테스트 코드를 작성하고 있었습니다. 그러다보니 로그인 폼에 포함되는 이메일 인풋 에서 진행했던 테스트와 유사한 테스트 코드를 반복해서 작성하고 있는걸 발견했습니다. 예를들어 이메일 입력에 유효하지 않은 이메일 입력이 들어오면 인풋 아래에 에러 텍스트가 보여야 한다 라는 테스트를 작성 했습니다. 그런데 로그인 폼에서 이런 로직을 포함하는 통합적인 로직을 테스트 하고 있었습니다. 이런 경우 로그인 폼에서는 이메일 인풋에서 작성한 테스트는 패스하고 좀 더 통합적인 테스트를 작성해야 할까요? 2. TDD를 도입한다면 어떤 테스트 코드부터 작성 되어야 하나요? 예를 들어 위 처럼 로그인 폼에 대한 통합 테스트가 있고 각 인풋 그리고 버튼 에 대한 유닛 테스트가 있다고 생각했을 때 어떤 테스트가 먼저 작성 되어야 하는지 궁금합니다. 통합 테스트를 먼저 작성하게 되면 이 통합적인 기능이 완료 되기 전까지는 계속해서 테스트가 실패 할 텐데 그래도 괜찮은가? 하는 궁금증이 있습니다!

프론트엔드 테스트에서 단위,통합,E2E 중 하나만 해야한다면 무엇을 해야할까요

안녕하세요. Nextjs를 사용하는 프론트엔드 신입 개발자입니다. 새 플젝을 시작하면서 테스트를 도입하려고 하는데 단위->통합->E2E 전체를 다 하기엔 시간적, 인력적 여유가 없을거같아 셋 중 하나만 채택하기로 결정되었습니다. 이런 경우 어떤 테스트를 진행해야 할까요? 현재 동료와 의견이 갈리고 있습니다. (컴포넌트 UI 테스트는 스토리북을 도입할 예정입니다) 동료의견 : 테스트에 많은 시간 할애할 수 없으니까 통합테스트를 하자. 단위는 작성할 코드가 많아서 시간이 오래걸릴거같다. E2E는 단위,통합 이후 부가적으로 진행되어야 하는거지 'E2E만' 하는건 제대로된 테스트가 안될거같다. 이런측면을 고려했을 땐 '통합테스트'만 하는게 좋을거같다 제 의견 : E2E에 대한 의견은 공감한다. 그런데 테스트에 들어가는 노동력을 최소화 하려면 오히려 단위테스트를 진행해야 할거같다. 통합테스트는 여러 기능이 유기적으로 얽혀있는 테스트 코드를 작성해야하니 오히려 테스트코드 작성에 시간이 더 오래 걸릴수도 있을거같다. 그리고 테스트 과정에서 문제가 발생하더라도 어느 기능이 문제인건지 추적하려면 단위테스트보다 훨씬 시간이 걸릴거같다. 사실 회사마다, 개발자마다 의견이 다른건 알고 있습니다! 하지만 저희가 시니어나 중간급 개발자가 없는 입장이라 조언을 구할곳이 없어 여기에 질문해봅니다. 감사합니다.

Spring Unit test @Value

프로젝트 중 외부에 노출되면 안되는 값이 있어 환경변수로 설정한 후 @Value 어노테이션을 사용해서 값을 사용했습니다. 테스트 코드를 작성하며 통합테스트를 진행하기엔 자원소모가 크다 생각하여 유닛테스트로 테스트 코드를 작성했습니다. 그런데 유닛테스트에서는 @Value에 의존성주입이 안되서 해결방법을 찾고있습니다. 제가 찾아본 해결 방법으로는 1. @SpringBootTest 사용 2. Reflection 사용 3. 생성자를 통한 주입 이렇게 3가지 방법이 있는데 2,3번 모두 테스트코드 내에서 직접 값을 입력해줘야해서 환경변수로 값을 보호하는 이점이 사라진다고 생각이 들었습니다. 이런 상황에선 어떻게 하는게 좋을까요? 환경변수가 들어가는 값을 테스트 할때 유닛테스트를 사용하는 접근방식부터 잘못된걸까요..? 현업에선 이런 민감한 정보를 어떻게 처리하는지 궁금합니다!

springboot 테스트코드 작성 방법

테스트코드에 관해 공부하게되었습니다. 정해진 답은 없는 것 같은데 잘못 이해하고 사용하고 있다는 생각이 들어서 질문 글을 올리게 되었습니다. 선배님들의 도움이필요합니다. 유저와 게시글 entity가 있고 게시글을 생성하는 기능을 controller service repository 로 작성했습니다. 1. 단위테스트를 작성할때 mock을 사용하여 Service.save 메서드에 대해 any()와 같이 저장할 객체와 저장된 객체를 제가 직접 지정하다보니 끼워맞춰서 성공을 받아내는 느낌이 강해서 어떻게 사용해야 하는지 궁금합니다. 2. 여러 글들을 읽어보고 고민해보니 Service.duplicate와 같이 이메일 중복체크와 같은 예외가 발생하는 것은 단위테스트로 작성하고 나머지 즉, crud와 같이 DB를 사용해야하는 기능은 controller 통합테스트를 작성해서 확인해야할 것 같은데 맞는 생각인지 궁금합니다. 3. controller 통합테스트에서 update와 같이 의존성이 많이 엮여있을 때 작성방법이 궁금합니다. 제가 생각한 바는 아래와같은데 어디까지 직접생성해주어야 할까요.. - 사용자를 저장하고 게시글도 저장한다. - 게시글을 읽어와 사용자가 게시글의 작성자인지 확인한다 - 게시글을 수정한다 - 수정된 게시글에서 빈 값은 없는지 등 유효성 검사를 하고 게시글을 저장한다 - 다시 게시글을 읽어와서 정상적으로 수정되었는지 확인한다. 아직 부족한것이 많아 단어사용이나 방식이 정말 바보같을 수 있는 부분 양해부탁드립니다. 긴 글 읽어주셔서 감사드립니다. 마지막으로 혹시 참고할 만한 springboot 테스트 코드나 책 또는 강의가 있다면 알려주시면 좋겠습니다. 정말 감사드립니다.

통합 테스트 관련해 질문드립니다!

안녕하세요 테스트 코드 관련해 질문드립니다. 통합 테스트에 대한 질문인데요! 단위 테스트들은 정상 작동 하게끔 완성했습니다. 여기서 통합 테스트도 만들어보고 싶은데 어떻게 만들어야 할 지 방향을 못잡겠습니다ㅠㅠ 단위 테스트들을 이어 붙여 테스트하는 것이 통합 테스트인가요? 아니면 다른 방법이 있다면 조언해주시면 감사하겠습니다 :))

다들 코드 리뷰는 어느 시점에 진행하시나요?

안녕하세요!! Code Review Rule을 만들고자 하는데 한 가지 인사이트를 얻고자합니다. 제가 궁금한 것은 Code Review를 어느 시점에 다들 하는지 궁금합니다. 저는 통합 테스트 환경에서 각자의 Feature들이 충분히 테스트된 후 기능에 문제가 없을 때 Code Review를 진행하는 방향으로 했으면 하는데 문제가 통합 테스트 환경에 배포하기 위해서는 develop에 merge가 되어야 하고 이렇게되면 Feature와 Develop간의 Diff가 없어 review가 어렵습니다. 여러분들은 어느 시점에 코드 리뷰를 진행하고 계신지? 그리고 위 문제와 비슷한 문제를 겪었다면 어떻게 해결 했는지 여쭤봐도 될까요??

Next.js TDD 어떻게 하고 계신가요?

안녕하세요! 전 직장까지는 AI 서비스기획/개발을 주로 하였으나, 현재 이직 후에는 Next.js를 활용한 프론트를 주로 개발하고 있는데요..! 그러다보니 Next.js(+TypeScript) 프론트 작업시, TDD 트렌드에 대해 잘 몰라 질문드리고자 이렇게 투표를 만들어보게 됐습니다. :D 각 회사/본인의 팀에서는 TDD를 어떻게 적용하고 계신지(Unit Test / 통합테스트) 감사하겠습니다.🙏 의견으로 상세히 설명해주시면 더더더더 감사합니다.😇 npm trends를 조회해보기도 했지만, 이미 시장 장악력의 의한 수치이거나 이미 CRA시 자동으로 들어가 있는 Jest와 같이 사용하지도 않는데 다운만되는 경우가 모두 포함된 경우라고 생각하니 진정한 의미에서의 Trend라고는 생각이 안되더라구요. 커리어리를 통해 함께 TDD Trends를 알아갈 수 있도록 함께해주시면 정말정말 감사하겠습니다 :)! 중복 투표 기능도 없고, 5개 이상 보기를 만들 수 없어서 ㅠㅜ 투표 기능이 참 아쉽습니다만.. 그래도 한 번 의견 주시면 감사하겠습니다! (커리어리 개발자님들 투표기능 업그레이드 부탁드려요!)