• 카테고리

    질문 & 답변

  • 세부 분야

    백엔드

  • 해결 여부

    미해결

테스트 질문 드립니다

24.03.27 00:00 작성 24.03.28 18:53 수정 조회수 161

1

1 서비스에서 체크후 예외를 던지는것과 stock에서 체크후 예외를 던지는 것은 다르다라는것이 잘 이해갸 되지 않습니다
강의 내용을 보아도 잘 이해가 되지 않아 굳이 이렇게 나눠야하는지에 대해 다시한번 설명 부탁드립니다 ㅜㅜ

 

또한 저는 stock 객체 자체에 판단할 수있는게 좋지 않나? 즉 stock의 책임이지 않을까?란 생각을 통해

service에서 stock 객체가 할일을 가지고 가면 응집도 면에서 좋지 않다라는 생각을 가지고 있는데요 이에 대해 어떻게 생각하시나요?

public boolean isQuantityLessThan(int quantity) {
        return this.quantity < quantity;
    }

    public void deductQuantity(int quantity) {
        if (isQuantityLessThan(quantity)) {
            throw new IllegalArgumentException("차감할 재고 수량이 없습니다.");
        }
        this.quantity -= quantity;
    }

 

2 테스트를 위한 코드

강의 내용 중 OrderCreateRequest와 관련되어 테스트를 위한 생성자가 생성되었다고 생각을 하는데요 테스트를 위한 코드에 대해 어떻게 생각하시는지 궁금합니다

 

저는 테스트를 위한 코드를 생성하면 안된다라고 생각하는데요

이유는 테스트를 위한 것으로 만들어 놨지만 다른곳에서 사용하게 되는 같은 현상이 발생될 수 있다라고 생각기때문입니다.

 


OrderCreateRequest request = OrderCreateRequest.builder()
                .productNumbers(List.of("001", "002"))
                .build();

 

3 어떤걸 어디서부터 어디까지 테스트해야되나?라는 의문입니다.

OrderService를 구현하면서 Order와 관련된 테스트(Order.create()등등)를 진행하였고 또한 주문을 통해 생성된 OrderResponse에 대한 테스트를 진행하는 것을 보았습니다.

 

아래는 Order와 관련된 코드입니다

public Order(List<Product> products, LocalDateTime registeredDateTime) {
        this.orderStatus = OrderStatus.INIT;
        this.totalPrice = calculateTotalPrice(products);
        this.registeredDateTime = registeredDateTime;
        this.orderProducts = products.stream()
                .map(product -> new OrderProduct(this, product))
                .collect(Collectors.toList());
    }

    public static Order create(List<Product> products, LocalDateTime registeredDateTime) {
        return new Order(products, registeredDateTime);
    }

    private int calculateTotalPrice(List<Product> products) {
        return products.stream()
                .mapToInt(Product::getPrice)
                .sum();
    }

이 코드에서 아래에 해당하는 코드만 테스트를 진행하셨는데요

this.orderStatus = OrderStatus.INIT;
        this.totalPrice = calculateTotalPrice(products);
        this.registeredDateTime = registeredDateTime;

만약에 위와 같은 컬럼이 끝이아니라 아래와 같이 수많은 컬럼이 있다면 이 모든것들을 다 테스트 해주어야 하는걸까요?

제 의문은 어떤것은 테스트하고 어떤것은 테스트 하지 말아야하나? 모든것들 전부 테스트 해야하나? 어디서부터 어디까지 테스트를 해야되지라는 정답이 없는 고민이 있어 강사님의 의견을 여쭙고자 질문을 드려봅니다

this.orderStatus = OrderStatus.INIT;
        this.totalPrice = calculateTotalPrice(products);
        this.registeredDateTime = registeredDateTime;
...
...
...
...
...
...은 컬럼을 의미합니다 아무거나 다른 컬럼을 생각해주셔도 좋습니다!

어떠한 한가지만을 테스트할때는 강사님이 말씀해주신것처럼 경계값이든 무엇이든 기준을 가지고 테스트를 진행하면 될텐데 OrderResponse나 그런것들 즉 어떤것에 의해 생성된것에 대해 테스트를 해야할때 어디서부터 어디까지 테스트를 해야하는지 잘모르겠습니다.

혹시 가능하시다면 어떤기준을 가지고 어떤것에 대해 테스트를 하시는지 어디서부터 어디까지 테스트를 해야하는지에 대한 생각을 가지고 있으시다면 말씀부탁드립니다

 

 

4 OrderService에 대한 테스트를 어디서부터 어디까지 어느정도 테스트해야하나입니다

 

지금은 아래와 같은 것들을 테스트 해주고 있는데요

assertThat(orderResponse.getId()).isNotNull();
        assertThat(orderResponse)
                .extracting("registeredDateTime", "totalPrice")
                .contains(registeredDateTime, 4000);
        assertThat(orderResponse.getProducts()).hasSize(2)
                .extracting("productNumber", "price")
                .containsExactlyInAnyOrder(
                        tuple("001", 1000),
                        tuple("002", 3000)
                );

 

만약 Order Service에 대한 로직이 복잡해지고 결제나 뭐 등등 이런것들이 증가가 된다면 그런부분들도 모두 test에서 검증을 해줘야하는걸까요?

 

만약 모두 그런부분들을 검증해준다고하면 구현부분이 조금 바뀐다고해도 테스트가 쉽게 깨질 수 있다라고 생각하는데요 그래서 생성이라면 생성과 관련된 테스트만 잘 테스트를 해야하는것인가 아니면 내부 구현에 대한 테스트도 진행을 해야하는것인가에 대한 의문이 있는데 강사님은 어떻게 생각하시나 궁금하여 질문을 드려봅니

 

 

5 앞에서 한 테스트를 뒤에서도 검증 해야하나? 라는 의문입니다

 

stock에 대한 단위테스트를 진행하면서 감소 메서드에 대한 테스트도 진행하였습니다.

그런데 OrderService에서 아래와 같은 코드로 검증을 해주는데요

List<Stock> stocks = stockRepository.findAll();
        assertThat(stocks).hasSize(2)
                .extracting("productNumber", "quantity")
                .containsExactlyInAnyOrder(
                        tuple("001", 0),
                        tuple("002", 1)
                );

항상 의문이었던 것은 다른 곳에서 테스트를 통해 검증이 끝난것도 다시 테스트를 해줘야하나라는 의문입니다.

이 코드 말고도 이와 비슷한 현상이 발생할 수 있을거 같은데요

다른 코드에서 검증을 진행해주는 코드를 앞 layer에서나 다른곳에서 쓸떄 또 검증을 해줘야하나라는 의문이 있습니다.

 

 6 메일에관한 테스트는 하지않는걸까요?

서비스테스트 중에 외부에 관한 즉 메일링 관련된 것은 목킹한것을 보았습니다. 그러면 메일에 관한 것은 단위테스트를 통해서 하는 것인지 아니면 그냥 잘동작하는것이라고 가정하고해야 하는걸까요? (그것을 테스트할 수 없기 때문에?)

7  밸리드는 모두 테스트?

프레젠테이션 레이어 즉 컨트롤러 테스트 중 밸리드에 관련된 부분은 보통 모두 테스트 하시는편인가요 아니면 정말 필요하다고 생각되시는 부분만 하시는지 궁금합니다.

모두 하면 모두 검증을하는거니 당연히좋겠지만 이것도 모두 비용이라 생각하는데 이런것들도 모두해야되나?라는 의문이 들어 질문드립니다

 

적다보니 의문이 많이 생겨 주절주절 적어봤는데요.. 좋은 테스트 코드를 지향하면서 테스트를 통해 깔끔하게 문서화하고 이를 통해 신뢰도 있는 프로그램을 만들지에 대한 고민을 하면서 정답이 없는 고민들에 대해 생각이 들었고 이 강의로 이끌리게 되었습니다 혹시나 제 질문이 잘이해가 되지 않으신다면 말씀부탁드립니다!

 

 

 

 

 

 

course-thumbnail

Practical Testing: 실용적인 테스트 가이드

Business Layer 테스트 (3)

강의실 바로가기

답변 2

·

답변을 작성해보세요.

0

박우빈님의 프로필

박우빈

지식공유자

2024.03.31

안녕하세요, answntjd1006 님!

와우 질문이 정말 많네요~! 하나씩 답변 드려보겠습니다.

 

1 서비스에서 체크후 예외를 던지는것과 stock에서 체크후 예외를 던지는 것은 다르다라는것이 잘 이해갸 되지 않습니다
강의 내용을 보아도 잘 이해가 되지 않아 굳이 이렇게 나눠야하는지에 대해 다시한번 설명 부탁드립니다 ㅜㅜ

또한 저는 stock 객체 자체에 판단할 수있는게 좋지 않나? 즉 stock의 책임이지 않을까?란 생각을 통해

service에서 stock 객체가 할일을 가지고 가면 응집도 면에서 좋지 않다라는 생각을 가지고 있는데요 이에 대해 어떻게 생각하시나요?

맞습니다. 일단 서비스에서 체크한 예외와 Stock에서 체크하는 예외 중 중요도가 높은 것은 당연 Stock입니다.
Stock의 재고 차감 로직은, OrderService 뿐만 아니라 다른 곳에서도 얼마든지 사용될 수 있기 때문에, Stock이 자기 자신을 보호하기 위해서 필수적으로 가져야 하는 validation 로직이라고 보시면 됩니다.

그럼 'OrderService에 예외를 미리 체크하지 않고, Stock에서 발행하는 예외를 사용해서 도메인 로직을 풀어내도 되었을텐데 왜 별도로 체크했는가?' 라는 의문에 대해서는, 강의 중에도 말씀드린 것처럼 클라이언트에 주고 싶은 메시지가 달라서이기 때문입니다.
Stock 입장에서 예외를 터뜨리는 상황은, 외부에서 어떤 로직을 전개하다가 재고 차감 로직을 호출했는지 Stock은 알 수 없기 때문에 범용적인 메시지로 예외를 발생시키지만, OrderService에서 주문을 생성하다가 재고를 차감하게 되는 상황은 명확히 어떤 맥락에서 재고 차감 관련 예외가 발생했는지 알고 있기 때문에, 그에 맞는 클라이언트향 메시지를 담아 예외를 발생시키고 싶을 수 있습니다.

다른 방법도 생각해볼 수 있는데요.
OutOfStockException 같은 custom 예외를 정의해서 Stock 내에서 발생시키고, 외부에서 이를 try-catch로 잡아 다시 원하는 예외 메시지를 담아 전파하는 방식을 적용해볼 수도 있습니다.

 

2 테스트를 위한 코드

강의 내용 중 OrderCreateRequest와 관련되어 테스트를 위한 생성자가 생성되었다고 생각을 하는데요 테스트를 위한 코드에 대해 어떻게 생각하시는지 궁금합니다

저는 테스트를 위한 코드를 생성하면 안된다라고 생각하는데요

이유는 테스트를 위한 것으로 만들어 놨지만 다른곳에서 사용하게 되는 같은 현상이 발생될 수 있다라고 생각기때문입니다.

저도 강의 중에 다루는 내용인데, 테스트 코드만을 위한 프로덕션 코드를 생성하는 것을 지양하자고 이야기 했습니다.
다만, 객체를 생성하는 생성자, builder 등의 경우 테스트 코드를 용이하게 작성하기 위한, 일종의 편의성을 위한 trade-off 라고 생각해주시면 좋을 것 같아요.

 

3 어떤걸 어디서부터 어디까지 테스트해야되나?라는 의문입니다.

OrderService를 구현하면서 Order와 관련된 테스트(Order.create()등등)를 진행하였고 또한 주문을 통해 생성된 OrderResponse에 대한 테스트를 진행하는 것을 보았습니다.

...

만약에 위와 같은 컬럼이 끝이아니라 아래와 같이 수많은 컬럼이 있다면 이 모든것들을 다 테스트 해주어야 하는걸까요?

제 의문은 어떤것은 테스트하고 어떤것은 테스트 하지 말아야하나? 모든것들 전부 테스트 해야하나? 어디서부터 어디까지 테스트를 해야되지라는 정답이 없는 고민이 있어 강사님의 의견을 여쭙고자 질문을 드려봅니다

어떠한 한가지만을 테스트할때는 강사님이 말씀해주신것처럼 경계값이든 무엇이든 기준을 가지고 테스트를 진행하면 될텐데 OrderResponse나 그런것들 즉 어떤것에 의해 생성된것에 대해 테스트를 해야할때 어디서부터 어디까지 테스트를 해야하는지 잘모르겠습니다.

혹시 가능하시다면 어떤기준을 가지고 어떤것에 대해 테스트를 하시는지 어디서부터 어디까지 테스트를 해야하는지에 대한 생각을 가지고 있으시다면 말씀부탁드립니다

좋은 질문이네요.
말씀하신대로 모든 필드를 테스트하는 것은 (물론 그러면 좋겠지만) 리소스 상 어려울 때가 많습니다.
그래도 최대한 많은 필드, 많은 범위를 검증하는 것이 좋고, 중요도가 높은 필드들을 중심으로 검증하는 것이 소프트웨어의 신뢰도를 높일 수 있는 방향입니다.

 

4 OrderService에 대한 테스트를 어디서부터 어디까지 어느정도 테스트해야하나입니다

지금은 아래와 같은 것들을 테스트 해주고 있는데요

...

만약 Order Service에 대한 로직이 복잡해지고 결제나 뭐 등등 이런것들이 증가가 된다면 그런부분들도 모두 test에서 검증을 해줘야하는걸까요?

만약 모두 그런부분들을 검증해준다고하면 구현부분이 조금 바뀐다고해도 테스트가 쉽게 깨질 수 있다라고 생각하는데요 그래서 생성이라면 생성과 관련된 테스트만 잘 테스트를 해야하는것인가 아니면 내부 구현에 대한 테스트도 진행을 해야하는것인가에 대한 의문이 있는데 강사님은 어떻게 생각하시나 궁금하여 질문을 드려봅니

그럴 때 필요한 것이 책임의 분리입니다.
조금의 요구사항이 변경되어도 테스트가 민감하게 반응하여 쉽게 깨지거나, 덩달아 변경 사항이 잦다면, 하나의 객체가 가지고 있는 책임이 너무 많지 않은지 고민해볼 필요가 있습니다.
만약 그렇다면, 적절한 책임에 따라 객체를 나눌 수 있고, 그에 맞게 각각 테스트를 진행할 수 있습니다. :)

 

5 앞에서 한 테스트를 뒤에서도 검증 해야하나? 라는 의문입니다

stock에 대한 단위테스트를 진행하면서 감소 메서드에 대한 테스트도 진행하였습니다.

그런데 OrderService에서 아래와 같은 코드로 검증을 해주는데요

 

항상 의문이었던 것은 다른 곳에서 테스트를 통해 검증이 끝난것도 다시 테스트를 해줘야하나라는 의문입니다.

이 코드 말고도 이와 비슷한 현상이 발생할 수 있을거 같은데요

다른 코드에서 검증을 진행해주는 코드를 앞 layer에서나 다른곳에서 쓸떄 또 검증을 해줘야하나라는 의문이 있습니다.

이 부분은 어느정도 비용이 있기 때문에 선택사항입니다만, 저는 그래도 권장을 하고 있습니다.
강의 중 이야기했던, A 모듈과 B 모듈이 결합하여 동작할 때, 우리가 기대한대로 동작하지 않을 확률도 존재합니다.
이런 상황을 모두 커버하기 위해서 상위 레이어에서도 비슷한 케이스를 검증한다고 이해하시면 됩니다.
지금은 예시 프로젝트라 프로덕트 자체가 복잡하지 않아서 충분히 가질 수 있는 고민이라고 생각하는데요, 복잡한 실무 케이스에서는 오히려 상위 레이어로 갈수록 엮여 있는 책임들이 많아서 통합적으로 테스트하는 것이 필요한 경우가 많습니다.

 

 6 메일에관한 테스트는 하지않는걸까요?

서비스테스트 중에 외부에 관한 즉 메일링 관련된 것은 목킹한것을 보았습니다. 그러면 메일에 관한 것은 단위테스트를 통해서 하는 것인지 아니면 그냥 잘동작하는것이라고 가정하고해야 하는걸까요? (그것을 테스트할 수 없기 때문에?)

자동화된 테스트 코드로 메일 전송 테스트를 할 수 있겠지만, 그러면 테스트 코드를 수행할 때마다 메일이 어딘가로 전송되어야만 합니다.
테스트 메일 계정을 만들어서 계속 거기다 메일을 전송하는 방법도 있지만, 메일 전송 비용이나, 이를 확인하는 비용도 발생하게 되는데요.

2가지 정도의 방법을 생각해볼 수 있습니다.

  • 메일 전송 테스트 코드를 만들어 놓고, 필요한 경우 수행해서 메일이 잘 전송되는지 확인한다. 사용하지 않을 때에는 @Disabled 처리를 하여 테스트 코드가 무시되도록 처리한다.

  • 메일 전송은 테스트 코드가 아니라, 개발자 검증 단계 / QA 단계 / 사용자 테스트 단계에서 사람이 수동으로 테스트한다.

7  밸리드는 모두 테스트?

프레젠테이션 레이어 즉 컨트롤러 테스트 중 밸리드에 관련된 부분은 보통 모두 테스트 하시는편인가요 아니면 정말 필요하다고 생각되시는 부분만 하시는지 궁금합니다.

모두 하면 모두 검증을하는거니 당연히좋겠지만 이것도 모두 비용이라 생각하는데 이런것들도 모두해야되나?라는 의문이 들어 질문드립니다

테스트 코드를 보셔서 아시겠지만, 조금 귀찮을 뿐이지 난이도가 높은 테스트 코드는 아니어서, 저는 꼼꼼하게 모든 필드를 검증하는 편입니다.
외부에서 들어오는 값이니 만큼 꼼꼼하지 않으면, 검증하지 않은 단 하나의 필드에서 문제가 생길 수도 있는 법이니까요.


도움이 되셨으면 좋겠네요.
감사합니다. 🙂   

answntjd1006님의 프로필

answntjd1006

질문자

2024.04.02

어우 질문 폭탄이었는데 답변 정말 감사드립니다.

3번 질문에 대한 답변을 해주신걸 바탕으로 생각을 하다보니 내가 현재 소프트웨어 신뢰도를 100%만족을 할지 아니면 어느정도 신뢰도를 떨어뜨리더라도 비용문제(시간적등등)을 생각해서 트레이드 오프를 해야할지 최선을 선택해야 겠다는 생각이드네요

솔직하게 당연히 모든 것을 테스트하는 것이 좋고 지향하지만 지향하는 것을 모두 할 수 없으니 참 고민이 많은 문제인것 같습니다 ㅜㅜ

 

다른 질문들은 모두 해소가 되었는데요 4번 질문은 아직 의문이 남아 추가적인 질문드려봅니다!

강사님께서 질문에 대한 답변중에 마지막에 적절한 책임에 따라 객체를 나눌 수 있고, 그에 맞게 각각 테스트를 진행할 수 있습니다라고 설명해주셨는데요

 

저는 결국에 Service에 그런 책임이 있는 객체들을 모여 협력을 이룰 것이라 생각하는데요

그런데 협력하는 객체들이 많아져 Service에 로직들이 많아지게 된다면 이런 로직들을 모두 검증해주어야 하는가에 대한 고민들이 들게 되더라구요 중요한 로직이니 모두 검증해주는 것이 당연히 좋겠지만 모든 것들을 다 하는 것은 쉽지 않을 뿐더러 엄청난 비용이라 생각이 들게되었습니다.

 

다른 질문에 대한 답변들을 보고 생각하다보니 당연히 모든것들을 검증하는 것이 좋으나 트레이드 오프를 생각해야겠다라는 생각이 들고 있습니다.

주문 생성시에는 재고가 감소되는것이 중요하니 아래와 같이 검증을 수행해야겠다.

또는 A + B가 어떻게 될지 모르겠는 것들은 검증을 해주자등등 생각이 드네요

List<Stock> stocks = stockRepository.findAll();
        assertThat(stocks).hasSize(2)
                .extracting("productNumber", "quantity")
                .containsExactlyInAnyOrder(
                        tuple("001", 0),
                        tuple("002", 1)
                );

또한 모든 것들을 검증해준다면 당연히 좋겠지만 문서가 너무 길어져 어떤 것들을 테스트하고싶은건지에 대해도 잘 생각해봐야할거 같구요 이런저런 생각이 들게되는데 강사님두 비슷한 생각이실까요? 아니면 다른 생각을 가지고 있으신지 궁금합니다.

 

테스트 참 어려운거 같네요 ㅜㅜ

어떤걸 테스트해야할지 선택하는 것도 어렵지만 선택하고도 어떤 컬럼들을 테스트해줘야하는지 등등 소프트웨어 신뢰도를 어떻게 향상시킬 수 있을지 너무 어려운거 같습니다 ㅜㅜ

0

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.03.29

안녕하세요, 인프런 AI 인턴입니다.

answntjd1006님, 꼼꼼한 질문 감사드립니다. 질문해주신 내용에 대해 순차적으로 답변 드리겠습니다.

  1. 첫 번째 질문과 관련해, 예외를 던지는 위치에 따른 차이점과 책임분배의 중요성에 대해 말씀드리자면, 서비스 레이어에서 예외를 던지는 것이라든가, ‘stock’ 객체에서 예외를 던지는 것 각각은 책임 소재에 따라 다르게 접근할 수 있습니다. ‘stock’ 객체 내부에서는 ‘stock’ 객체의 상태를 확인하고 예외를 던지는 것이 캡슐화와 응집도 측면에서 적절합니다. 이는 객체 스스로의 상태를 책임지게 함으로써 관련 로직의 이해와 수정이 용이해지는 장점이 있습니다. 반면, 여러 도메인 객체의 상태를 통합적으로 평가해야 하는 경우라면 서비스 레이어에서 예외를 던지는 것이 적합할 수 있습니다. 이처럼 예외 처리의 위치는 설계의 의도와 객체 간의 책임 분배에 따라 달라질 수 있습니다.

  2. 테스트를 위한 코드 작성에 대해서는 의견이 분분할 수 있습니다. 명확한 경계를 두고 테스트를 위해 필수적인 최소한의 코드를 작성하는 것은 무방하다고 볼 수 있으나, 테스트를 위한 코드가 실제 운영 코드에 영향을 주거나, 운영 환경에서 불필요하게 사용되는 경우를 피해야 합니다. 테스팅의 목적과 품질을 위해 필요한 경우에 한해서 적절히 활용될 필요가 있습니다.

  3. 어느 범위까지 테스트해야 하는지에 대한 질문에는 테스트의 목적과 중요도를 고려해 결정해야 합니다. 일반적으로, 핵심 비즈니스 로직, 시스템의 안정성과 직결되는 부분, 사용자에게 큰 영향을 주는 기능 등은 철저히 테스트하는 것이 중요합니다. 단, 모든 코드를 100% 테스트하는 것은 실질적으로 불가능할 수 있으므로, 위험도 분석, 변경 빈도, 이전 버그 발생 경험 등을 종합적으로 고려하여 테스트 우선순위를 결정해야 합니다.

  4. OrderService의 테스트 범위와 관련하여, 중요한 것은 해당 서비스의 핵심 기능과 엣지 케이스를 아우르는 테스트를 설계하는 것입니다. 시스템 내 로직이 복잡해지거나 다양한 결제 시나리오 등이 추가될수록, 그에 따라 관련 테스트 케이스도 확장되어야 합니다. 테스트가 깨지는 것을 우려하기보다는, 변경에 따른 영향을 신속하게 파악하고, 올바른 동작을 보장하기 위한 목적으로 테스트를 진행해야 합니다.

  5. 앞서 진행한 테스트의 검증 결과를 다른 곳에서도 활용할지 여부는, 테스트의 중복성과 효율성, 그리고 테스트의 명확성 사이의 균형을 고려하여 결정해야 합니다. 한 부분에서 이미 검증된 로직을 다시 테스팅할 필요는 줄일 수 있으나, 통합 테스트나 시스템 전반의 테스트에서는 다시 검증이 필요한 경우도 있습니다.

  6. 외부 서비스나 메일 같은 부분의 테스트는, 실제로 외부 의존성을 가진 기능을 직접 테스팅하기보다는 목 객체(Mock)를 활용하여 그 행위를 흉내 내는 방식으로 접근하는 것이 일반적입니다. 실제 서비스를 사용하는 테스트는 외부 요인에 의존하게 되므로, 가능한 한 통제 가능한 환경 내에서 테스팅하는 것이 바람직합니다.

  7. 유효성 검사(validation)에 대한 테스트의 범위와 관련해서는, 해당 검증 로직이 중요한 비즈니스 규칙을 다루는 경우, 또는 시스템의 안정성과 직결되는 경우에는 꼼꼼하게 테스트하는 것이 좋습니다. 허나, 모든 유효성 검사를 같은 수준으로 테스트하는 것이 아니라, 위험도와 중요도에 따라 테스트의 우선순위를 조정하는 접근이 필요합니다.

말씀하신 바와 같이 좋은 테스트 코드 작성과 신뢰도 있는 프로그램을 위한 고민은 정답이 없는 부분이 많습니다. 각각의 상황과 목적에 맞게 적절히 접근하는 것이 중요할 것입니다. 추가적인 질문이 있으시면 언제든지 질문해주세요.

이 글과 비슷한 Q&A