가장 기본적인 차원에서 보면, Exercism의 중심에는 테스트와 테스팅이 있어요. 테스트는 구현을 앞으로 나아가게 하고, 연습 문제가 언제 완성되는지 알려주거든요.
즉각적인 피드백
Pharo는 테스트 작업과 점진적 테스트를 훌륭하게 지원해요! 테스트 케이스 클래스나 메서드 옆의 orb를 클릭하면 연습 문제의 어떤 테스트든 실행할 수 있어요.
테스트 orb는 마지막 테스트 실행 결과에 따라 색이 달라져요:
- 통과하면 초록색
- 단언이 실패하면 노란색
- 런타임 오류나 예외가 발생하면 빨간색
순서가 정해진 테스트
Exercism 연습 문제의 테스트는 실행 순서를 분명히 하기 위해 일부러 번호가 붙어 있어요(예: test01_verifySomeProperty, test02_verifyAnotherProperty 등).
연습 문제를 풀 때는 첫 번째 테스트의 orb를 클릭해서 실패 원인과 통과에 필요한 것이 무엇인지 파악한 다음, 풀이에 코드를 추가해서 통과시키는 걸 권장해요. Pharo에서는 이런 변경을 디버거에서 하는 게 아주 흔한 일이에요. 디버거에서는 코드 편집기와 함께, 문제를 이해하는 데 도움이 되는 모든 변수와 매개변수를 볼 수 있거든요.
참고: 테스트에 순서 접두사를 붙이는 건 일반적인 관행이 아니며, 자신의 프로젝트에서 테스트를 작성할 때는 이렇게 하면 안 돼요.
깨져 있어도 실행할 수 있어요
Pharo는 코드가 깨져 있어도 기꺼이 실행하고, 오류가 발생하면(구문 오류든, 잘못된 값이든, 심지어 없는 클래스나 메서드든) 디버거가 그냥 다시 열려요. 이 방식은 테스트 주도 개발에 큰 영향을 주었고, 아무 연습 문제의 첫 번째 테스트를 실행해 보면 이 접근법을 맛볼 수 있어요. 디버거는 풀이 클래스를 찾을 수 없다고 곧바로 알려줘요(아직 아무것도 작성하지 않았으니까요). 편리하게도 "Create" 버튼이 있어서 빠진 클래스를 추가하고, 실행이 끝나거나 또 다른 오류가 발생할 때까지 계속 실행할 수 있어요.
첫 번째 테스트를 하다 보면, 아직 메서드를 하나도 작성하지 않았기 때문에 다음에는 두 번째 오류를 만나게 돼요. 이때도 디버거의 "Create" 버튼으로 메서드를 정의하고 계속 실행할 수 있어요. 이 시점에서는 스택 트레이스에서 더 아래쪽을 클릭해 들어가 실패한 테스트의 요구 사항을 살펴보고, 새 메서드를 수정해서 통과시킬 수도 있어요.
디버거와 친해지기
개발을 어느 정도 진행한 뒤에는 스택에서 더 뒤로 돌아가 "Restart" 버튼으로 프로그램 실행을 이전 지점에서 다시 시작하는 게 유용할 수 있어요. 그러면 프로그램을 한 단계씩 실행하면서 무슨 일이 일어나는지 볼 수 있거든요. 프로그램이 왜 제대로 동작하지 않는지 이해하는 중요하고 유용한 방법이에요.
디버거에서 변수를 보는 것뿐만 아니라, 아무 문이나 골라서 inspect/print를 클릭하면 그 문을 평가한 결과를 볼 수도 있어요. 이건 메서드의 결과를 테스트할 때나 객체의 내부 상태를 살펴볼 때 유용해요.
디버거에서 실행 중인 코드를 바꿀 수도 있다는 걸 잊지 마세요. 변경 사항을 저장하면 방금 저장한 메서드에서 실행이 다시 시작될 뿐이에요. 덕분에 아직 그 상황에 머무른 채로 변경을 실험하고 결과를 볼 수 있어요.
정리하자면, Pharo에서 디버거를 쓰는 걸 두려워하지 마세요. 디버거는 문제를 이해하고 실험하는 데 도움을 주는 값진 도구라고 생각해요.
더 큰 테스트 그룹과 자동화
더 큰 테스트 그룹을 실행해야 할 때는 Package 메뉴에서 실행할 수도 있고, Test Runner 도구(World 메뉴에서 열거나 <meta> + OU를 입력)를 사용할 수도 있어요.
Playground에서 print evaluating으로 테스트를 프로그래밍 방식으로 실행할 수도 있어요:
AllExercismTests suite run.
테스트의 내부 구조에 대해 더 알고 싶다면 SUnit을 읽어 보거나 TestCase 계층 구조의 코드를 살펴봐요.
알고 계셨나요: 테스트 주도 개발은 SUnit 테스트 라이브러리의 도입을 통해 Smalltalk에서 탄생했어요
