테스트코드 작성하는 진짜 이유는 이거 아니냐?

[익명(104.28)]

수동으로 테스트하기 귀찮아서..

나는 다른것보다 이게 제일 큰듯..

[익명(121.125)]

맞음 제일 원탑임

[김대기(waitkim)]

테스트 제대로 짜보면 카타르시스 오질텐데요 ㅎㅎ 기능 추가나 변경에도 기존 기능의 정상 동작을 보장하기 위해 테스트를 작성합니다

[익명(104.28)]

ㄷㄷ

[김대기(waitkim)]

제어 로직과 io 처리가 복잡하게 얽히고 테스트도 불가능하고 수정도 못해 버그는 나와.. 노답 코드를 로직과 io 부분 대강 분리해낸 후, 테스트케이스 작성해서 로직만 빠르게 테스트하고 통합테스트로 io 부분과 붙여서 테스트 한다음에 코너케이스 발견되면 테스트케이스에 추가해서 로직부분 다시 유닛테스트 돌리고

[김대기(waitkim)]

기능 완성되면 리팩토링으로 로직 부분 예쁘고 이해하기 쉽게 수정! 정상 동작은 테스트가 보장 ㅋㅋ 개꿀!

[익명(104.28)]

죄송한데 질문 드려도 될까요? 제어로직이 무엇인지 궁금합니다 io처리는.. db에 쓰는거랑 업로드 이런건가요? 제어로직과 io처리를 구분하는것이 왜 중요한지도 궁금합니다

[김대기(waitkim)]

io는 말씀하신게 맞구요 보통 외부와 엮이기때문에 가볍게 테스트하기가 힘듭니다 게다가 테스트 할 필요도 적고 기능을 변경할 일도 별로 없습니다 io는 최대한 단순하고 멍청하게 시키는거만 잘하도록 짜면 됩니다 외부에서 잘 응용해서 쓸 수 있게요

[김대기(waitkim)]

제어로직 테스트는 10초도 안걸리는데 io까지 통합테스트하려면 일단 스프링 떠야하고 어쩌고 저쩌고.. 골치가 아프죠 심지어 데이터까지 수정되고 비용까지 발생합니다

[김대기(waitkim)]

더 큰 문제는 io와 제어로직을 함께 테스트 했을때, 뭐가 어디서 잘못된건지 분석하기가 힘들다는 겁니다 분기 구문으로 여기서 이러면 저렇게 io 하기도하고 이렇게 io 하기도 하고 혹은 또다른 제어로직을 거치기도하고 지랄이 나죠

[김대기(waitkim)]

제어로직을 분리하면 a를 넣어서 어떻게 처리할지가 다 결정된 b가 나옵니다 그리고 io에서는 b대로 쭈우욱 처리하면 끝납니다

[익명(104.28)]

상세한 답변 매번 너무 감사합니다ㅠㅠ

[익명(223.62)]

젠킨스로 배포직전에 기능변경으로 인한 예상못한 부작용을 막아줄수있는 최후의 보루, 안전장치라고 생각