Page tree
Skip to end of metadata
Go to start of metadata
총 세번으로 나누어 Selenium과 Cucumber를 활용해 웹 테스트를 자동화하는 방법에 대하여 다루었다.

아직 Selenium과 Cucumber를 본격적으로 사용하지 않고 테스트를 위한 기반을 마련한 상태이기 때문에 실제로 적용해 가면서 많은 부분을 보완해야 할 것으로 생각한다.

위 세 문서는 자바 개발 환경에 Selenium과 Cucumber를 적용하기 위한 과정에 대하여 집중적으로 다루었다. 하지만 Selenium과 Cucumber를 사용하는 것이 중요한 것이 아니라 테스트에 대한 필요성을 인식하고 프로젝트에 참여하는 구성원들이 지속적으로 테스트 코드를 개선해 나가는 것이 더 중요하다. 모든 소스 코드가 그렇겠지만 테스트 코드는 조금만 관심을 가지지 않으면 쉽게 깨진다. 한번 깨지기 시작하면 걷잡을 수 없을 만큼 확대되는 것이 테스트 코드이다.

다음으로 중요한 부분은 feature 문서를 잘 작성하는 것이다. Selenium과 Cucumber를 사용하는 것이 중요한 것이 아니라 feature 문서를 잘 쓰고, 지속적으로 잘 관리해 나가는 것이 훨씬 더 중요하다. 특히 Cucumber를 사용할 경우 feature 문서를 변경하면 StepDefinitions 소스 코드까지 수정해야 하기 때문에 유지보수 비용이 좀 발생할 듯하다.

feature 문서를 어떻게 작성하는 것이 좋을지에 대해서는 Modern Cucumber and Rails: No More Training Wheels 문서를 참고해 보면 좋겠다. 좋지 않은 feature 문서와 이를 어떻게 개선해 나갔는지를 보여주고 있어 좋은 feature 문서를 작성하는데 참고 자료가 되리라 생각한다.

오늘 팀에 이 내용을 공유했더니 다음과 같은 내용을 공유해 주어 Cucumber의 다른 측면을 고민해 볼 수 있었다.

오늘 개발파트 회의때 소개된 cucumber 관련 글입니다.
cucumber와 rspec의 차이점 검색하다가 보게 되었는데요.

http://www.jackkinsella.ie/2011/09/26/why-bother-with-cucumber-testing.html

영어의 압박이 있긴 한데 읽어보면 나름 논리는 있습니다.
읽어보니 cucumber 디스글은 아니고, 프로그래머 레벨에서 cucumber를 쓰는게 잘못되었고 왜 그런지 이야기합니다.

<3줄 요약>
1. 많은 프로그래머들이 cucumber를 integration test로 잘못 사용하고 있다.

2. cucumber의 용도는 보다 하이 레벨의 분석툴이며, 이를 acceptance test용으로 사용하기에는 프로그래머 입장에선 불편한 점이 많다.

3. 당신이 프로그래머라면 cucumber를 integration test로 사용하면서 불편하게 살지 말고, 그럴 바에야 acceptance test 안한다는거 인정하고 Capybara 같은 pure integration test 도구를 사용해라.

<1줄 요약>
1. 프로그래머 레벨에서는 cucumber 쓰지 마라.

모든 도구가 은총알이 될 수 없듯이 Selenium과 Cucumber가 모든 문제를 해결할 수 없다. 자신의 현재 상황에 맞춰 도구를 선택하고 지속적으로 개선해 나가는 노력을 기울일 때 도구를 제대로 활용할 수 있으리라 생각한다. 일단 기반만 마련했으니 끝났다는 생각으로 접근한다면 어떤 도구도 모든 요구사항을 만족시켜 줄 수 없다.

위 피드백을 준 친구가 ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series 책이 나왔다고 소개해 주었는데 이 책도 Cucumber로 예제를 진행하고 있다. 단, 언어는 Ruby다. 영어로 되어 있고, 자바는 아니지만 전체적인 개념을 잡는데 유용할 듯하다.

오늘 개발파트 회의에서 나온 한 가지 이슈는 "주도적으로 feature 문서를 만들고 StepDefinitions을 만드는 파트는 QA일 것이기 때문에 자바보다는 Ruby가 더 직관적이고 좋겠다."는 의견이었다. QA의 경우 프로그래밍 경험이 많지 않거나 거의 없기 때문에 처음부터 새롭게 시작하는 상황이라면 Ruby가 좋겠다고 생각했다. 하지만 문제가 발생할 경우 빠르게 지원할 수 있는 개발자가 현재 팀에 없기 때문에 자바로 진행하는 것이 좋겠다는 결론을 내렸다. 이 같은 결정을 내려야하는 상황이 종종 있는데 새로운 기술을 도입하고 싶지만 현재 개발자들이 보유하고 있는 기술과 유지보수성을 무시할 수 없기 때문에 종종 이 같은 결론을 내린다. 아무래도 조금씩 Ruby도 좀 파야할 시점인가보다. 최근에 Ruby가 자꾸 내 옆에서 알짱거리는 것을 보니 말이다.