흠냐~_~의 아스트랄 플레인

1. 테스트 목록을 우선 결정해라(나와야 하는 공식, 필요한 변수, 변수의 위치, 변수의 종류, 예상되는 부작용 등등)
2. 컴파일이 되든 안되든 일단 테스트 목록을 테스트할 코드를 먼저 만들어라.
3. 그후 필요한 추가로 필요해진 사항들을 테스트 목록에 넣어라(필요한 클레스. 필요한 예외 처리 등등)
4. 위의 1~3을 반복


최대한 중복이 없도록 테스트 코드를 고쳐 나가야 한다.
테스트를 빨리 통과 시키기 위해 return에다가 원하는 값을 넣어버려도 상관없다. 단 테스트 목록에 해당 행위의 해결을 추가 해야 한다.
목표는 "작동"하는 깔끔한 코드.
테스트 코드를 수정할 때는 최대한 외형을 유지한다.(정확한 예측은 불가능 하므로 바뀔 수는 있다)
테스트와 코드의 결합도를 낮추기 위해 테스트 되는 객체에 새 기능을 추가
객체간에 동통 되는 부분이 생기면 일반화 해라




참조 : 테스트 주도 개발

공통점
 - 둘다 스마트 포인터 객체
 - auto_ptr과 shared_ptr의 객체 소멸자에서 delete 사용( 따라서 동적 할당 된것은 제대로 삭제가 안된다 )
   auto_ptr<string> aps(new string[10]);  // 이러면 망함


차이점
 - auto_ptr이 가지고 있는 특정 객체를 다른 auto_ptr에 대입하면 원본이 null이 된다.
   auto_ptr<Test> pTest1( CreateTest() );   //pTest1은 CreateTest()에 의해 생성된 객체
   auto_ptr<Test> pTest2( pTest1 );     //pTest2는 pTest1이 가르키던 객체. pTest1은 이제 null
   pTest1 = pTest2;                            //pTest1은 이제 자신이 처음 가르키던 객체. pTest2는 이제 null
 - shared_ptr은 중복해서 가질 수 있다.(레퍼런스 카운터를 가지는 방식)



참조 : 이팩티브 C++ 항목 14