켄트 벡(Kent Beck)23 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (27장) [27장] 테스팅 패턴 작은 테스트 케이스를 작성하고 그 작은 테스트 케이스가 실행되도록 하라. 그 후에 다시 원래의 큰 테스트 케이스를 추가하라. 빨강/초록/리팩토링 리듬은 성공이 지속되는데 중요하다. 나는 큰 테스트를 작성하고 나면 우선 교훈을 찾기 위해 노력한다. 왜 테스트가 그렇게 컸을까? 어떤 다른 방식을 취했더라면 좀더 작게 만들 수 있었을까? : 가짜 객체(Fake It)와는 다르다. 스스로 검증할 수 있는 능력이 있고, 외부에서 결과값을 조정할 수 있다. 비용이 많이 들거나 복잡한 리소스에 의존하는 객체를 테스트하려면 어떻게 해야 할까? 상수를 반환하게끔 만든 속임수 버전의 리소스를 만들면 된다. 마치 데이터베이스인 것처럼 행동하지만 실제로는 메모리에만 존재하는 객체를 통해 작성될 수 있다.. 2020. 2. 15. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (26장) [26장] 빨간 막대 패턴 목록에서 다음 테스트를 고를 때 무엇을 기준으로 할 것인가? 여러분에게 새로운 무언가를 가르쳐 줄 수 있으며, 구현할 수 있다는 확신이 드는 테스트를 고를 것. 사실은 상향식, 하향식 둘 다 TDD의 프로세스를 효과적으로 설명해 줄 수없다. 첫째로 이와 같은 수직적 메타포는 프로그램이 시간에 따라 어떻게 변해 가는지에 대한 단순화된 시각일 뿐이다. ‘성장’은 일종의 자기유사성을 가진 피드백 고리를 암시하는데, 이 피드백 고리에서는 환경이 프로그램에 영향을 주고 프로그램이 다시 환경에 영향을 준다. 둘째로, 만약 메타포가 어떤 방향성을 가질 필요가 있다면 (상향 혹은 하향보다는) ‘아는 것에서 모르는 것으로(known-to-unknown)’라는 방향이 유용할 것이다. 우리는 아는.. 2020. 2. 14. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (25장) [25장] 테스트 주도 개발 패턴 -테스트한다는 것은 무엇을 뜻하는가? -테스트를 언제 해야 하는가? -테스트할 로직을 어떻게 고를 것인가? -테스트할 데이터를 어떻게 고를 것인가? 소프트웨어를 어떻게 테스트할 것인가? 자동화된 테스트를 만들어라. 아주 확신에 찬 사람과 정말 얼렁뚱땅 넘어가는 사람을 제외한다면, 아무리 작은 변화라도 테스트하지 않고 릴리즈하지는 않는다. 실제로 변화를 테스트하는 것은 ‘테스트를 갖고 있다’는 것과 똑같지 않다. 양성 피드백 고리(positive feedback loop). 스트레스를 많이 받으면 테스트를 점점 더 뜸하게 한다. 테스트를 뜸하게 하면 당신이 만드는 에러는 점점 많아질 것이다. 에러가 많아지면 더 많은 스트레스를 받게 된다. 어떻게 하면 이 고리에서 빠져나올.. 2020. 2. 13. 테스트 주도 개발(Test-Driven Development:By Example) - 2부 : xUnit 예시 (24장) [24장] xUnit 회고여러분이 xUnit을 직접 구현해볼 만한 두 가지 이유1.숙달:xUnit의 정신은 간결함에 있다. 직접 만들어 사용하면 숙달된 도구를 쓰는 느낌을 받게 될 것이다.2.탐험:새로운 프로그래밍 언어를 청므 접하면 그 언어로 xUnit을 만들어본다.xUnit을 사용하다 보면 단언(assertion)의 실패와 나머주 종류의 에러 사이에 큰 차이점이 있음을 알게 될 것이다.낙관적(동적) 타이핑(typing) 언어에서는 인터페이스에 대한 충성을 선언할 필요도 없다. 그냥 해당 오퍼레이션을 구현하면 된다. 2020. 2. 12. 테스트 주도 개발(Test-Driven Development:By Example) - 2부 : xUnit 예시 (22 ~ 23장) [22장] 실패 처리하기우리가 원하는 건 테스트가 독립적으로 실행되는 것이다. 우리는 항상 테스트를 먼저 작성해야 한다는 사실을 의식적으로 상기해야만 한다. [정리]-중요한 문제를 발견했는데 이를 바로 처리하기보다는 할일 목록에 적어두었다. [23장] 얼마나 달콤한지놓친 디자인 요소를 찾기 위해 일부러 만드는 중복이 아니라면, 중복은 언제나 나쁘다. 우리는 테스트들을 모아서 한번에 실행할 수 있는 기능을 원한다. 테스트를 한 번에 하나씩만 실행시킨다면 테스트가 독립적으로 돌아가도록 만들기 위해 고생하는 건 별 의미가 없다.매개 변수 수집(collecting parameter) 패턴중복이 상당히 많은데, 주어진 테스트 클래스에 대한 테스트 슈트를 자동 생성할 방법이 있다면 그 중복을 제거할 수 있을 것이다.. 2020. 2. 11. 테스트 주도 개발(Test-Driven Development:By Example) - 2부 : xUnit 예시 (20 ~ 21장) [20장] 뒷정리하기 테스트가 계속 서로 독립적이길 바란다면 외부 자원을 할당받은 테스트들은 작업을 마치기 전에 자원을 다시 반환할 필요가 있다. 단순하게 생각하면 할당 해제를 위한 테스트 방법은 역시 또 하나의 플래그를 도입하는 것이다. 호출된 메서드의 로그를 간단히 남기는 식으로 테스트 전략을 바꿀 생각이다. 항상 로그의 끝부분에서만 기록을 추가하면 메서드 호출 순서를 알 수 잇게 될 것이다. 플래그 대신에 로그를 검사하도록 변경 [정리] -플래그에서 로그로 테스트 전략을 구조 조정했다. [21장] 셈하기 일반적으로 테스트를 구현하는 순서는 중요하다. 난 다음에 구현할 테스트를 선택할 때, 나에게 뭔가 가르침을 줄 수 있고 내가 만들 수 있다는 확신이 드는 것을 선택한다. 모든 테스트가 성공하던 매시.. 2020. 2. 10. 이전 1 2 3 4 다음