직접적인 사용자 테스트는 개발/기획 단계에서 생각하지 못했던 문제들을 손쉽게 알려 준다. 개발자의 관점이 아닌 사용자의 관점에서 프로그램을 어떻게 바라보는지 알 수 있게 해 준다. 사용자가 기능을 어떻게 이해하는지, 어떤 부분에서 어려움을 느끼는지 확인할 수 있다. 다만 사용자 테스트를 하기 위해서는 어느 정도의 준비가 필요하다. 적당한 사용자를 포섭해야 하고, 테스터는 그 사용자의 행동을 볼 수 있어야 한다. 다행인 것은 문제점들을 확인하기 위해서 많은 사용자를 대상으로 사용자 테스트를 할 필요는 없다고 한다. Jakob Nielen 의 글을 보면 6명의 사용자가 프로그램을 사용하는 것을 지켜보면 프로그램의 문제점들을 대부분 알 수 있다고 한다.
웹서비스를 개발하고 있다면, 여기 사용자 테스트를 위한 한 가지 멋진 툴이 있다. Userfly 는 사용자의 행동들 – 마우스 이동/클릭, 키보드 입력 – 을 저장해서 나중에 확인할 수 있게 해 준다. 즉 사용자가 사이트에 들어와서 한 행동들을 다시 재현할 수 있다. userfly의 사용방법은 매우 간단하다. 회원가입 하면 제공되는 javascript 코드를 페이지의 <head> 태그 안에 넣어주기만 하면 된다. 이 때부터 들어오는 사용자의 행동들이 기록되기 시작한다. 기록된 내용은 userfly 사이트에서 확인할 수 있다.
userfly.com from Chris Estreich on Vimeo.
userfly 사이트에서는 기록된 내용을 확인할 수 있을 뿐만 아니라, 기록을 잠시 중단 할 수도 있고, 특정 IP에 대해서 기록을 하지 않도록 설정할 수도 있다. 무료 사용자는 한 달에 10개의 사용자 기록을 저장할 수 있다. 10개 이상을 저장하고 싶다면 유료 모델로 전환해야 한다. 값은 비교적 저렴하다. 1000개를 기록하는데 25$이다.
사용하면서 아쉬웠던 점들은
- userfly는 굉장히 무거운 javascript를 사용하고 있는 듯 하다. 모든 사용자 행동들을 userfly 서버로 전송해야 할 테니 그럴 만도 하다. 그래서 IE6에서는 티가 날만큼 느려진다.
- javascript를 제대로 재현하지 못하는 듯이 보인다.
'그 밖에..' 카테고리의 다른 글
| 인간중심 인터페이스 4장 정량화 (0) | 2009/09/06 |
|---|---|
| Userfly : 사용자의 동작을 지켜보자. (0) | 2009/09/03 |
| CSS를 이용해서 프린트 친화적인 페이지 만들기 (0) | 2009/09/02 |
| Jruby로 RED5 애플리케이션 만들기 (0) | 2009/04/07 |
| RED5 설치와 데모 애플리케이션들 (0) | 2009/04/07 |
| SSH Turneling (0) | 2009/03/24 |
ruby on rails로 개발할 때에 이어 C#을 이용하는 지금도 테스트 코드를 쓰고 있다. rails로 개발할 때는 rspec만이 최고이고 다른 환경에서는 테스트를 쓰기가 어렵지 않을까 라는 생각을 가졌었는데, 분명히 그렇지 않은 것으로 판명되었다. C#으로 개발하는 요즘 테스트 코드 쓰는 것에 상당한 재미를 느낀다. 언어 자체를 봤을 때는 ruby가 C#보다 훨씬 더 유연하다. 그래서 mocking을 할 때 편한 것은 사실이다. 약간 불편함, 그리고 낯설음이 있음에도 불구하고 C#으로 테스트를 쓰는 것이 편하게 느껴지는 이유가 무엇일까 생각해 본다.
우선 테스트 수행속도를 들 수 있다. C#에서는 테스트 수행 속도가 매우 빠르다. 결과를 곧바로 알 수 있어서 진행에 막힘이 없다. 테스트 주도 개발은 테스트를 쓰고 실패하는 테스트를 보고, 실제 코드를 쓰고 성공하는 테스트를 보는 일을 계속 반복해야 한다. 이 때 테스트 속도가 느리다는 것은 큰 문제가 된다. rails는 테스트 속도가 느린 편이다. 속도를 빠르게 하기 위해서는 drb를 사용해야 한다. 좋아하는 IDE가 drb를 제대로 지원하지 못하는 경우가 있는데, 난감하다.
한 테스트 단위로 실행할 수 있는 것도 편리하다. 내가 수정한 테스트만 실행하면 테스트 수행 속도도 빨라진다. rails로 개발할 때는 autotest를 사용해서 수정된 부분에 해당하는 테스트만 실행하도록 할 수 있었다.
테스트 수행속도와 더불어 테스트 결과를 보여주는 UI도 매우 중요하다. 깔끔한 Red-Green 테스트 결과를 볼 수 있는 것은 코드를 작성하는데 리듬을 살려준다. 이 때 실패한 테스트의 스택 트레이스와 바로가기 링크는 필수다. Resharper가 보여주는 테스트 결과는 훌륭하다. 좋은 IDE는 개발의 즐거움은 물론이고, 생산성도 크게 향상시킬 수 있다. Resharper의 단축키, 인텔리 센스, 메소드 스텁기능, 그리고 빠른 속도 모두 프로그래밍에 재미를 준다.
좋은 테스팅 프레임웍도 테스트 코드를 쓰는 것을 즐겁게 해 준다. ruby에서의 rspec. C#에서 사용한 xunit.net과 moq. 두 프레임웍은 rspec만큼은 아니지만 테스트 코드를 간결하게 작성하는데 도움을 준다.
언어 자체가 가지고 있는 간결함, 그리고 유연함도 언급하지 않을 수 없다. rspec을 사용할 때 무엇이든 mocking가능하다는 사실은 테스트를 훨신 수월하게 쓸 수 있도록 한다. 반면 moq의 제약사항(virtual 메소드와 interface만 mocking할 수 있다.)는 좀 답답함을 느끼게 한다.
정리하자면 테스트를 즐겁게 쓰기 위해서는 테스트 수행 속도, 좋은 UI가 매우 중요하다. ruby 언어가 더 유연하고 rspec이 뛰어남에도 불구하고 C#에서 테스트를 쓰는 것이 ruby 못지 않게 재미있었던 이유는 좋은 테스트 UI와 실행속도 밖에 없다.
'이야기' 카테고리의 다른 글
| 접근성(Accessibility) (0) | 2009/09/17 |
|---|---|
| 지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유 (0) | 2009/09/06 |
| TDD의 요건 (0) | 2009/06/09 |
| 아이콘 : 스티브 잡스 (0) | 2009/05/21 |
| 넛지(Nudge) (0) | 2009/05/20 |
| 독서법 (0) | 2009/05/20 |
요즘 주로하는 업무는 C#을 이용합니다. 익숙함을 벗어나는 것에는 스트레스가 따르지만, 새로운 것을 배운다는 것은 즐거운 일이기도 합니다. 익숙해진 ruby에 비하면 불편하고, 복잡하게 느껴지기도 하지만, 그런 불평들은 아마도 무지함에 대한 다른 표현들이겠지요.
C#에 대해 조금씩 알아나가게 되면서 느끼는 것은 언어가 서로 서로 닮아간다는 것입니다. C#은 스크립트 언어가 아님에도 불구하고 스크립트 언어만큼 유연성을 주는 기능들이 추가되어 가고 있습니다. 3.0에서는 lamda 기능이 추가되었고 닫혀있는 클래스의 method 확장도 되며, C# 4.0 에서는 dynamic typing도 된다고 합니다.
ruby로 일하면서 가장 좋았던 것 중 하나는 rspec이었습니다. C#으로 테스트 코드를 작성하려면 어떤 것들이 필요할까? 라는 생각으로 조사를 좀 해 봤습니다. 테스트에 관련된 라이브러리들이 생각보다 많아서 놀라기도 하고, 당혹스럽기도 했습니다. 찾고자 하는 것은 가장 멋진 test framework과 가장 멋진 mocking framework이었습니다. 독보적은 지위를 갖는 것은 없었지만, 마음에 드는 것을 결정할 수는 있었습니다. xUnit.net과 moq입니다.
덤으로 ReShaper 같은 훌륭한 비쥬얼 스튜디오 툴도 있다는 것도 알게 되었습니다. 아직 제대로 사용해 본 것은 아니지만, TDD를 하기에 충분히 잘 갖추어진 환경이라는 생각이 듭니다.
'C#' 카테고리의 다른 글
| [C#] region을 사용해서 코드를 깔끔하게 (0) | 2009/06/08 |
|---|---|
| [C#][moq] TcpClient와 같이 sealed된 class mocking하기 (3) | 2009/05/19 |
| [C#] is 와 as (0) | 2009/05/14 |
| [C#] Resharper, unittest.net, moq를 이용해서 unit test 만들어보기 (0) | 2009/05/12 |
| [C#] 숫자(int) 혹은 문자열(string)을 바이너리(byte)로 변환하기 (1) | 2009/04/25 |
| [C#] 테스트 주도 개발(TDD)을 해 보자. (2) | 2009/04/20 |
파일을 업로드 하는 controller 의 action을 만들었다. 그 action을 테스트하기 위해서는 파라미터에 업로드하는 파일을 전해주어야 하는데, 어떻게 할 수 있을까?
fixture_file_upload 를 사용하면 된다.
- @upload_file = fixture_file_upload("files/test_ppt.ppt", "application/data")
첫번째 파라미터는 파일 이름, 두번째 파라미터는 mime type 이다.
그리고 test_ppt.ppt 파일을 fixtures/files 디렉토리에 넣어 두면 된다.
이 글은 스프링노트에서 작성되었습니다.
'Rails > 테스트' 카테고리의 다른 글
| [Rails] model_stubbing 플러그인 사용 (0) | 2008/07/25 |
|---|---|
| [Rails] file upload test (0) | 2008/05/28 |
| [Rails][Selenium] Selenium을 이용해서 test record하기 (0) | 2008/03/07 |
| [Rails] Selenium on rails 사용하기 (0) | 2008/03/07 |
| [Rspec] Error가 발생했어요 (0) | 2008/02/15 |
| [Rails][Rspec] controller의 test (0) | 2008/02/15 |
