나는 TDD를 처음 접했고 구현 코드 앞에 올 때 첫 번째 테스트를 만들 때 문제가 있습니다. 구현 코드에 대한 프레임 워크가 없으면 첫 번째 테스트를 자유롭게 작성할 수 있지만 원하는 Java / OO 방식으로 문제가 발생하는 것으로 보입니다.
예를 들어, Github ConwaysGameOfLifeExample 에서 내가 작성한 첫 번째 테스트 (rule1_zeroNeighbours)는 아직 구현되지 않은 GameOfLife 객체를 만들어 시작했습니다. 존재하지 않는 set 메소드, 존재하지 않는 단계 메소드, 존재하지 않는 get 메소드를 호출 한 다음 어설 션을 사용했습니다.
테스트를 더 작성하고 리팩토링하면 테스트가 발전했지만 원래는 다음과 같습니다.
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}이 초기 단계에서 첫 번째 테스트를 작성하기로 결정한 방식에 따라 구현 설계를 강요하면서 이상한 느낌이 들었습니다.
TDD를 이해하는 방식으로 괜찮습니까? 리팩토링을 통해 시간이 지남에 따라 테스트 및 구현이 진화했다는 점에서 TDD / XP 원칙을 따르는 것 같습니다. 따라서이 초기 디자인이 쓸모없는 것으로 판명되면 변경하기에 개방적이지만 이 방법으로 시작하여 솔루션.
사람들은 어떻게 TDD를 사용합니까? GameOfLife 오브젝트, 프리미티브 및 정적 메소드만으로 시작하여 리팩토링 반복을 더 많이 수행 할 수 있었지만 너무 많은 생각이 들었습니다.
5
TDD는 신중한 계획이나 신중한 디자인 패턴 선택을 대체하지 않습니다. 즉, 처음 몇 줄의 테스트를 만족시키기 위해 구현을 작성하기 전에 계획이 어리 석거나, 잘못된 패턴을 선택했거나 심지어 테스트가 요구하는 방식으로 클래스를 호출하는 것은 어색하거나 혼란 스러워요.
—
svidgen
