Property-Based Testing with PropEr, Erlang, and Elixir (Fred Hebert, 2019) 독후감
’테스트’라고 하면 ’유닛 테스트(Unit Testing)’를 떠올린다. 좀 더 해상도를 높여서 테스트 코드를 상상하면 ’예제 기반 테스트(Example-based Testing)’을 떠올린다.
’테스트’라고 하면 ’유닛 테스트(Unit Testing)’를 떠올린다. 좀 더 해상도를 높여서 테스트 코드를 상상하면 ’예제 기반 테스트(Example-based Testing)’을 떠올린다.
속성 기반 테스트 프레임워크인 PropEr, PropCheck를 사용하면 ’Cache 예제코드를 테스트하며 맛보는 Stateful Property-Based Testing’ 예제를 손쉽게 병렬 테스트로 바꿀 수 있다.
속성 기반 테스트(Property-Based Testing)라 하면 Stateless Property를 사용한 테스트를 연상한다. 상태가 없는(stateless) 속성이다. 즉 입력에 대한 결과가 항상 같아야 한다.
’예제로 보는 Property-Based Testing (feat. Kata09: Back to the Checkout)’ 글에서 ’Kata09: Back to the Checkout’ 코드를 짜고 속성 기반 테스트(Property-Based Testing)를 했다. 짠 테스트를 ...
’속성 기반 테스트(Property-based Testing)와 속성 정의에 도움을 주는 네 가지 방법’ 글에서 속성 기반 테스트를 간략히 살펴봤다. 대략 감은 잡겠지만 속성 기반 테스트를 짜라고 하면 막막하다. 이럴 때는 좋은 예제가 도움을 줄 수 있다.
속성 기반 테스트(Property-based Testing)에 대해 들어본 적이 있다. SUT(System Under Test)에 대한 속성(Property)을 정의한다. 테스트 프레임워크 도움을 받아서 테스트를 자동화한다. 하지만 유닛 테스트(Unit Testing)를 처음 접했...
단위 테스트(Unit Testing)에 관한 책을 한 권만 꼽는다면 이 책을 꼽고 싶다. 늦게 알아서 억울한 책이다. 예제가 C#이지만 자신이 사용하는 언어와 상관없이 읽으면 도움이 되는 내용들로 가득하다.
데이터베이스에 값을 저장하고 로드하는 건 스텁(Stub)이나 목(Mock)으로 대체해야 할까? 그냥 직접 사용해도 되는 걸까? 달빛조각사 게임에서는 데이터베이스에 목을 사용하지 않고 테스트를 했다. 통합 테스트(Integration testing) 레벨로 테스트를 짰다. 그러면 통...
테스트 대상이 되는 SUT(System Under Test)와 협력자(Collaborator) 사이에 일어나는 상호 작용을 검사할 때, 테스트 대역(Test double)을 사용한다. 테스트 대역은 크게 목(Mock)과 스텁(Stub)으로 나눌 수 있다. ’단위 테스트 (블라디미르...
단위 테스트(Unit Testing)에서 단위(Unit)의 경계는 무엇일까? OOP(Object-Oriented Programming) 언어로 테스트를 짜고 있다면 클래스(Class)를 단위로 생각하면 되는 걸까? FP(Functional Programming) 언어로 테스트를 짜...
구현 세부 사항(Implementation Details)을 테스트하지 말아야 한다. 리팩터링하면 쉽게 깨지는 테스트가 되기 때문이다. 테스트 코드는 리팩터링을 안전하게 할 수 있게 지켜주는 방어막인데, 장애물이 되어 버린다. 리팩터링했는데, 고쳐야 하는 테스트가 많다면 구현 세부...
’단위 테스트 (블라디미르 코리코프, 2021)’ 책의 ’7장 가치 있는 단위 테스트를 위한 리팩터링’을 보고 정리한 내용이다. 모든 코드를 테스트할 수는 없다. 그래서 중요하고 의미 있는 영역부터 테스트를 짜야 한다. 중요한 영역부터 시작해 덜 중요한 영역까지 테스트 커버리지를 ...
구성이 마음에 들어서 책을 읽었다. otp, ecto schemas, ecto queries, phoenix를 테스트하는 방법이 목차에 담겨있다. 언어만 elixir로 바꾼 일반 테스팅 책이 아니라는 기대가 있었다. 하지만 막 감탄하면서 읽지는 않았다. 주제가 달라진다고 테스트하는...
팀 패스워드 관리 프로그램 tpass 개발하면서 간단하게 만들어서 썼다. 독립된 환경을 가진 유저 2 명으로 테스트를 해야 했기 때문에 테스트 환경에 공을 들였다. 독립된 환경을 구축하는 데 docker를 사용했다. 스크립트 언어로 bash를 사용했다.
컴퓨터 프로그램의 구조와 해석(SICP), 해커와 화가 책을 통해 Lisp에 대한 빠심을 계속 충전해왔다. 이제 그 막연한 빠심을 실체화해야 할 시기.
테스트 코드도 계속 관리해야 하는 코드다. 릴리즈 빌드에 포함이 안 된다고 해서 악취가 진동하게 놔뒀다가는 하나만 고쳐도 엄청나게 많은 테스트 코드가 깨지는 등 감당을 못하게 된다. 좋자고 하는 건데, 테스트 코드가 오히려 병목이 될 수도 있다. ’Invoice를 테스트하려니깐 C...
TDD(Test-Driven Development, 테스트 주도 개발)를 처음 접했을 때, 개발 방법이 충격적이었다. 테스트를 먼저 추가하면서 시작되는 TDD의 리듬을 타면 테스트가 바탕이 된 매우 견고한 코드로 갈 수 있을 것 같다. 하지만 낯선 개발 방법에 적용하는 시간과 노력...
```c++ class CCAImage { protected: void SetSnapRegion(int x, int y, int dx, int dy); };