스마트 컨트랙트가 제대로 동작하는지 간단히 테스트하기에는 Remix가 가장 좋습니다. 이더리움 클라이언트 설정할것도 없고 gas 비용지불하기 위한 이더도 별도로 필요하지 않기 때문입니다. 또한 기본적으로 디버깅 기능을 제공해서 빠르게 오류를 수정할 수도 있습니다.
- 이더리움 클라이언트 설정할 필요 없음
- 테스트에 쓸 수 있는 100이더가 들어있는 5개의 테스트 계정 제공
- 디버깅 기능 제공
앞에서 작성한 스마트 컨트랙트 코드를 Remix 코드 입력창에 입력합니다.
https://remix.ethereum.org
몇가지 warning이 발생하는데, 스마트 컨트랙트의 생성자로 constructor라는 이름을 사용하라는 것과 this.balance에서 this의 타입을 명시적으로 address 타입으로 하라는 경고 메시지입니다. 이것은 별다른 조치하지 않고 넘어가겠습니다. 솔리디티 업데이트 빨라서 이와 같은 warning이 자주 발생합니다.
1. 스마트 컨트랙트 Deploy 테스트
작업 순서
- Remix의 Run탭에서 Environment의 드랍박스에서 "Javascript VM 선택
- Deploy버튼 옆의 min_down_price에 적절한 값 입력 (예, 100 wei)
- Deploy버튼 클릭
그러면 위와 같은 화면이 나오게 됩니다. 한가지 중요한 사실은 솔리디티에서 public으로 선언한 상태변수의 상태를 읽는 함수는 기본으로 제공된다는 것입니다. 예를 들어, author라는 변수가 public으로 선언되었기 때문에 별도로 "getAuthor"와 같은 함수를 만들 필요가 없습니다. Remix에서 deploy되고 나면 "author"라는 상태변수의 값을 읽어오는 버튼이 생깁니다.
그리고 Deploy 버튼을 눌렀을 때 왼쪽 하단의 Debug창에 아래와 같이 문제가 없이 Deploy가 제대로 되었다는 메시지가 나타납니다. 문제가 있다면 Failure 메시지가 나타날 것입니다.
Deploy를 하고 나서, 상태변수들의 값을 읽어보세요.
2. contribute 테스트
다음으로 contribute 함수에 대한 동작을 테스트 해보겠습니다. contribute 함수는 사용자가 웹페이지에서 contribute 버튼을 누르면 호출되는 함수입니다. 여기서 테스트할 것은 사용자가 contribute 버튼을 클릭했을 때, 스마트 컨트랙트의 balance가 입력한 만큼 증가하는지와 해당 사용자의 주소가 contributor 리스트에 들어가는 것입니다.
2.1 balance 테스트 작업 순서
- Remix의 Run탭에서 Account에서 다른 계정을 선택 (컨트랙트를 Deploy한 계정과 다르게)
- 바로 밑에 Value 칸에 1을 입력하고, 단위를 ether로 설정 (balance 차이를 분명하게 볼 수 있음)
- Deploy된 컨트랙트의 함수 중에 contribute를 클릭
- Account에서 선택한 계정이 contribute 함수를 실행하는 것임
- Deploy된 컨트랙트의 함수 중에 getSummary를 클릭
- 결과로 표시되는 첫번째 값이 컨트랙트의 balance 값임.
위와 같이 실행하고 스마트 컨트랙트의 balance가 증가하는지 확인하면 됩니다.
2.2 contribute 테스트 작업 순서
- 2.1의 테스트를 전부 실행함
- Deploy된 컨트랙트에서 contributors 버튼을 클릭
- 2.1 테스트에 사용한 계정을 복사해서 붙여 넣음
- contributors 확장화면에 call 버튼 클릭
위와 같이 하면 아래와 같이 해당 계정이 contributor인지 아닌지 true, false로 표시됩니다. 이 경우는 당연히 true로 표시됩니다.
3. Download 테스트
contribute/contributor 테스트와 동일하기 때문에 생략하겠습니다. 주의할 점은 download 함수 실행은 contributor만 가능합니다. contributor가 아닌 계정으로 다운로드 버튼을 클릭하면 error message가 발생합니다.
디버그 메시지에는 관련없는 내용이 나타나서 오류를 잡기 어려울 수도 있습니다.
download 함수가 제대로 실행되면 아래와 같이 "getSummary" 버튼을 클릭했을 때, download 수가 증가한 것(세번째 표시값)을 볼 수 있습니다.
4. approveWithdrawal/finalizeWithdrawal 테스트
contributors가 컨트랙트에 누적된 balance 금액을 인출하는 것에 동의하고, author가 인출하는 것을 테스트해보겠습니다.
4.1 approveWithdrawal 작업 순서
contribute, download와 유사합니다.
- contribute를 수행한 계정을 선택
- approveWithdrawal 버튼 클릭
- approvals에 approve한 계정을 입력하고 결과값 확인
- approvals_count 버튼을 클릭하여 값이 증가하는지 확인
위와 같이 하면 아래와 같이 제대로 동작하는 것을 확인할 수 있습니다.
4.2 finalizeWithdrawal 작업 순서
4.1 테스트의 상태에서 다음과 같이 작업합니다.
- author 계정을 선택
- finalizeWithdrawal 버튼 클릭
finalizeWithdrawal 버튼 누르기 전의 author 계정의 잔액은 99.999 이더입니다.
finalizeWithdrawal 버튼을 누른 후 author 계정의 잔액을 확인해 보면 1 이더정도가 증가했음을 알 수 있습니다.
코딩한 DreamStory 스마트 컨트랙트의 기본 기능 몇가지를 테스트 해봤습니다. 의도한 대로 잘 작동하네요. 몇가지 테스트는 생략했는데 직접 해보시길 바랍니다. minimum download price보다 적은 금액으로 다운로드하면 어떻게 되는지도요. 주의할 것은 require로 함수 실행을 제한했는데, 이것들이 발생했을 때 debug 메시지가 이와 관련되지 않아 오류 해결이 쉽지 않을 수 있습니다. 이 부분은 로깅 기능을 추가해야 개선해야 겠습니다.
다음은 보다 체계적으로 테스트 환경을 꾸미고 테스트 해보겠습니다. debug 메시지 출력 기능도 포함해서요.
오늘의 실습: 코딩을 하고 나서 테스트를 하는 이유에 대해서 생각해 보세요.
