#유닛테스트

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

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

리액트에서 유닛테스트에 대해 질문이 있습니다!(RTL)

요즘 테스팅에 관심이 생겨서 기존에 있던 프로젝트로 유닛 테스트를 하나씩 해보고 있습니다. 유닛테스트 중 어떻게 테스트하는게 좋은 방법인지 궁금해서 질문드립니다 아래와 같은 카테고리 컴포넌트에서 React-Query를 사용하고 있습니다. 별로의 useQuery를 커스텀 훅으로 분리시켜놓은 상태이구요. 다음 컴포넌트를 유닛테스트 한다고 했을때, useCategoryQuery hook과 ui 부분에 대한 테스트는 별도로 분리시켜야 하는걸까요?? 분리해야 한다고 했을 때에는 useCategoryQuery 훅은 모킹하는게 맞는 부분인가요?? useQuery를 테스팅 하는 래퍼런스를 찾아봤는데 useQuery에 대한 테스트만 진행하는 로직 같아서 아리송해서 질문드립니다ㅠㅠ!

Spring Unit test @Value

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

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

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

프론트엔드 테스트코드 어떻게 하세요?

안녕하세요. 2년차 프론트엔드로 일하고 있는 주니어입니다. 사내에 테스트코드 도입 전 혼자 해보고있는데요, tdd를 하고 계시는 다른 현직자 분들에게 궁금한점이 있습니다. 유닛 테스트 : jest, vitest E2E 테스트: cypress, playwright 위의 도구로 이것저것 해보고있는데 하면서 까다로운 점이 있습니다. 일반 유틸 함수 같은 것은 유닛테스트가 비교적 간단하지만 프론트 엔드이다 보니 컴포넌트 테스트를 하려면 무조건 DOM 으로 불러와야하고, 사이즈가 큰 컴포넌트는 뭔가 잘 되지도 않고, 이럴거면 그냥 E2E만으로 하면 되지 않나 라는 생각도 들고... 실제로는 unit 테스트 도구로 컴포넌트 dom으로 불러와서하고 e2e도 따로 하시나요? 아니면 e2e로만, unit으로만 이렇게 한가지로만 하시나요??

프론트엔드 테스트시 모킹 범위가 궁금합니다.

안녕하세요 테스트에 대해 궁금한 것이 있어 질문을 작성하게 되었습니다. 리액트를 사용한 프로젝트에 테스트를 도입할 계획입니다. 해당 프로젝트의 주문과 결제 과정까지를 테스트할 수 있는 테스트 코드를 작성하고 싶습니다. 주문 과정까지의 api 호출이 굉장히 많은 상황입니다. 품절, 프로모션, 상품 정보 조회 등등 테스트를 할 때 주문 과정까지에 필요한 "모든 api"를 msw를 사용하여 모킹을 한 후 테스트를 진행해야 하는건가요? 하나 더 궁금한 것은 react에서 유닛테스트를 하게 된다면 각각의 함수를 테스트하게 되는 것인지 궁금합니다. 그렇다면 컴포넌트를 제외한 함수들은 모두 테스트를 하기 위해 커스텀 훅으로 만들거나 컴포넌트 외부에서 정의해야 하는 건가요?

api가 개발 완료되면 dev모드에서도 msw 사용을 안하는게 올바른가요?

사이드 프로젝트를 진행중인데, api가 개발 완료되기 전까지는 msw를 통해 API 모킹을 처리했습니다. 하지만 더미 데이터 만으로 테스트를 하기 힘든 컴포넌트가 있고, 실제 API가 개발이 완료되었는데 굳이 데이터도 적은 msw로 테스트를 진행 해야 하냐는 팀원의 의견이 있어, 아직 개발이 완료되지 않은 상태임에도 msw를 끄게 되었는데 dev모드인 만큼, 과도한 서버 요청으로 서버에 부하가 걸릴 수 있거나 아직 미완성인 api가 있을 경우 오히려 테스트하기 어려운 상황도 있을거라고 생각이 들어서 더미 데이터가 많이 않아서 테스트를 못하는 기능(컴포넌트)은 유닛 테스트 이상의 테스트 과정을 더 추가해서 처리하는게 맞는 것 같은데, 어떻게 생각하시는지 궁금합니다!

jest환경에서의 export * from './*' 이슈

안녕하세요 react native로 테스트코드를 짜다가 막힌 개발자입니다 저는 주로 hooks라는 폴더가 있으면 그 안에 index.ts를 만들어서 이와 같은 레이어의 폴더,파일들을 전부 export * from './*' 하여 실제로 사용할때 import { someHook } from 'hooks' 이렇게 사용하고 있었습니다. 구현 및 동작에는 오랫동안 이슈가 없었지만 이번에 유닛테스트를 도입하면서 jest가 'hooks'라는 놈을 import하는 파일을 테스트할 시 그 안에 모든 파일들을 읽어서 테스트실패가 아닌 jest에러를 계속 만나고 있습니다.. 노가다 mocking을 하여 어느정도 막았지만 테스트할 파일이 아닌 파일에서 계속 에러가 등장해서 babel과 jest의 config를 계속 수정해봤지만 해결이 되지않아 이렇게 자문을 구합니다. 추가로 웹에서도 이러한 export * 을 사용한 index.ts패턴을 사용할 때 성능 등의 이슈가 없는지 궁금합니다!