[포럼으로 옮깁니다]

Question

게시판 선택을 잘 못 했네요. 포럼으로 옮깁니다. 자신이 잘 알지 못하는 대상을 증오하는 건 부끄럽고 해악한 일입니다. 정치사회적으로 생각해보면 쉽게 납득됩니다. 비슷한 일이 테스트 자동화와 관련해서도 많이 발견됩니다.테스팅이 쓸모 없거나 시간만 잡아먹는다고 말하는 사람들은 제대로 된 테스팅 학습이나 현장 경험이 없습니다. 인터넷이나 세미나에서 귓동냥 정도 얻은 것이 전부거나, 공부도 안하고 무작정 시도해 보다가 금새 어렵다고 포기한 사람들이죠. 제대로 사용하는 수준에 이르기 위해 공부를 안해도 되거나 어려운 난관이 없는 소프트웨어 개발 도구는 한 번도 본 적이 없습니다. 준비없는 무모한 시도나 이른 포기는 테스팅의 잘못이 아니라 자신의 잘못인데 테스팅을 비난하기 시작합니다.이것과 관련되어 몇 년 전 엉클밥 인터뷰가 있으니 관심있는 분들은 읽어보시는 것도 좋겠습니다. 추가로 설계가 얼마나 중요한지, 또 코딩과 설계가 얼마나 밀접한 것인지도 얘기합니다.https://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html*참고로 저는, 국내에도 많은, 엉클밥 추종자들 중 한명이 아닙니다.그리고 테스트 케이스는 버그가 있다는 것은 알려주지만 버그가 없다는 것은 알려주지 않습니다. 이것도 이해하지 못하고 TDD 하면 버그가 하나도 없느냐고 반박하는 사람들이 있습니다. 버그를 완전히 박멸해주는 개발 도구는 아직 발견되지 않았습니다. 테스팅과 TDD는 만능이 아닙니다. 그저 여러가지 도구 중 하나입니다. 손톱을 깎을 때 니퍼를 쓰다 다치면 그건 니퍼가 아니라 사람 잘못이에요. 위 글에서 엉클밥은 TDD는 암을 치료하지도 세계 평화를 가져다주지도 못한다고 했죠. 마지막으로, 다음 글은 켄트벡이 말하는 TDD의 효과(번역)입니다.https://gyuwon.github.io/blog/2018/06/24/what-tdd-solves.html

deev · Answer

잘 모르는 대상을 거부하고 늘 하던 방식으로 하고자 하는건 사람의 심리인 것 같습니다.저는 예전에 테스트코드를 비판하는 포스팅을 보면서 테스트코드는 필요없고 해도 그만 안해도 그만이야라고 생각했었습니다.지금 생각해보니 그 내면에는 새로운 것을 배우는 것이 어렵고 그에 대한 거부감이 있었던 것 같습니다.지금은 테스트코드를 능수능란하게 쓰지는 못하지만 그래도 예전에 비해 거부감없이 중요한 부분에서는 반드시 테스트코드를 쓰려고 노력하고 있습니다.물론 실제로 여러번 해보고 그에 대한 단점이 더 많다고 판단하여 결정을 내린 경우에는 다양성이라고 생각할 수 있지만 무언가를 제대로 해보지 않고 섣불리 판단하는건 위험한 것 같습니다.

양탕구리 · Answer

저는 이제 테스트코드 없이 잘 짜는 방법을 모르겠습니다.적당한 크기로 모듈화 된다는 장점도 있고내 코드가 잘 돌아갈거라는 믿음을 가지고 작업할 수 있어서 자신감있게 일할 수 있는것 같습니다.사용하는 테스트러너에 익숙하기만 하다면테스트코드를 짜고서 코드를 짜는게 개발 속도면에서도 효율적이라고 생각합니다.

방가방가2 · Answer

테스트 자동화가 배보다 배꼽이 더 큰 경우가 있습니다. 실 환경에서는 테스트를 할 수 없으니, 테스트를 위한 임시 시스템을 만들고, 여기서 테스트를 해야 하는데 이 시스템들에 임시 데이터 넣어주고 테스트 할 때 마다 이전 테스트에 영향을 받지 않게 초기화시켜 주는 작업도 만만치 않습니다. 오히려 테스트 구축에 개발 보다 더 많은 시간이 들어 갑니다. 또, 공용 테스트 인프라를 사용할 수 도 없는게, 그 테스트를 진행하는 다른 사람들의 작업에도 영향을 미치게 됩니다. 그리고, 테스트를 자동화하려면 이런 인프라들을 구성해야 하는데, 이 인프라들을 코드로만 작성할 수 없는 경우도 많습니다. 테스트를 위한 시스템 리소스를 할당하는 것도 만만치 않습니다.

앙앙이 · Answer

저 같은 경우 게시판을 만들때 DB 3개가 필요하더군요. (1) 관련된 모든이들이 바라보는 개발기(2) 부하 테스트용(3) 단위 테스트용 DB 3개 유지 보수하기 힘들더군요. 계속 DB 테이블 구조는 바뀌기 때문에 그렇때마다 일치 시키려면 죽겠네요.유지 보수가 매우 어렵지만 부하테스트용 DB 통해서 게시글 천만개일때 쿼리문 최적화등등에 대해서 고민을 하고 실력을 향상 시킬 수 있었습니다. 또 단위 테스트를 지속 발전시킬 수 있었구요.하지만 어디까지나 이건 혼자하는 프로젝트라 가능한 이야기라 생각합니다. 실전에서 1인 프로젝트처럼 할 수 없기때문에 어떻게 접근해야 할지 막막하네요.

charlatan · Answer

테스트는 당연히 중요합니다. 하지만 여기서 또 어떤 괴리감이라고 해야 하나, 마치 &#34;개발자&#34;에 대해 자신만의 스테레오 타입 같은 것이 있듯이 &#34;테스트&#34; 역시 그런 범주에 있지 않나 하는 생각이 듭니다. &#34;테스트를 모르면서&#34;에서 그 &#34;테스트&#34;의 의미 말입니다.개발자는 프로그램을 작성하고나서 당연히 어떤 식으로든 테스트를 합니다. 대부분은 단위 테스트에 머무는 경우가 많은데 사실 이것 역시 자신의 프로그램에서 충분히 결정가능한 범위라면 이런 저런 필요한 테이터를 만들어서 테스트를 할 수 있겠죠. 하지만 그렇지 않은 경우도 많습니다. SI에서 일한 경험으로 보면, 아마 SI에 대한 좋지 않은 인식때문인지는 모르겠지만, 우리나라 SI의 특성상 보통 자신이 개발한 프로그램의 커버리지를 파악하기 힘듭니다. 단순 CRUD라고 해도 테이블 수가 최소한 5-6개는 되고 각 테이블의 컬럼 수가 수십개 되는 경우가 많습니다.더구나 해당 컬럼 하나 하나가 거의 업무와 연관되어 있기 때문에 테이블 정의서만 봐서는 어떤 형태의 데이터가 들어가는지 알 수가 없습니다. &#34;123&#34; 같은 의미없는 문자열로 가장 기본적인 CRUD를 테스트하는 것에 만족할 수 밖에 없죠. 더구나 단위테스트 코드를 작성할 여유도 별로 없습니다(테스트의 중요성를 부정하는 것이 아닙니다). CRUD로 끝나면 다행이지 EAI에서 인터페이스되거나, 새롭게 추가되는 시스템, 또는 외부 결제 시스템과의 연계 등등 그런 부분이 있다면 개발자의 개발일정상 &#34;완료&#34;가 사실상 완료가 아닌 것이 되는 상황이 많습니다. 흔히 말하는 그 &#34;테스트&#34;도 레벨과 목적에 따라 단위테스트, 통합테스트, 시스템 테스트,인수 테스트 등등 많고, 또 테스트 설계 기법에 따라서도 장황한데 테스트를 반드시 해야 한다고 말하는 분들이 의미하는 테스트가 구체적으로 어떤 것을 의미하는지 모르겠습니다. 짐작컨데 사람들마다 자기 분야에서의 테스트는 각각 다를 것 같습니다.SI에서는 일반적으로 테스트 시나리오 테스트 케이스 명세 등은 분석설계 단계의 산출물입니다. 그렇다면 SI에서 테스트를 해야하는 대상은 업무의 흐름에 따라 설계 단계에서 작성된 산출물을 기반으로 테스트 코드를 작성하는 것을 말합니다. 본인이 개발한 코드를 본인이 확인하는 것을 테스트로 생각하지 않습니다. 그건 당연히 어떤 식으로든 하는 것이고요.아무튼 SI 개발자들에게는 테스트 코드를 작성한다는 것은 현실적으로 어려운 점이 많습니다. 매번 느끼지만 &#34;테스트&#34;라고 했을 때... 서로 자신이 만져본 &#34;코끼리&#34;를 정의하는 것 같습니다.

sbroh · Answer

https://okky.kr/article/605647위의 글과 같은 내용입니다. 실수로 2개가 올려졌는데요, 댓글 다실 분은 위의 링크에 해주시기 바랍니다.

[포럼으로 옮깁니다]

6개의 답변

Q&A 목록