방금 시작 했으므로 테스트를 아직 작성하지 않았습니다. (나는 근본 주의자가 아니며, 테스트가 없기 때문에 컴파일 오류가 맘에 들지 않습니다.) 하지만 나는 XML 매핑에 따라 고정 된 길이의 플랫 파일 레코드를 구문 분석하는 프로젝트를 시작하여 어디서부터 (모든 파일 레이아웃의 상위 집합을 나타내는 클래스로), 클래스 세부 사항을 DB에 작성하기 전에 시작해야하는지 궁금합니다. 표.텍스트 파일 가져 오기 프로젝트의 TDD
외부 요인이 너무 많아서 그들을 모방하고 싶지 않으므로이 프로젝트를 주도하는 테스트를 시작하는 좋은 방법은 어디서 어떻게 될까요?
문제를 부분적으로 분해하는 것이 전부입니다. 몇 가지 예 :
이시도가 제공하는 각 클래스는 하나의 책임을지고, 의존성을 결정하고, 그것들을 주입합니다. Th at, mock/stubs의 도움을 받아 각 클래스를 개별적으로 테스트 할 수 있습니다.
글쎄, 테스트하고 싶지만 조롱하고 싶지는 않습니다. 나는 그것이 당신에게 integration tests 또는 acceptance tests이라고 써 줄 것을 믿습니다. 테스트에서 설정을 많이해야만 테스트가 깨지기 쉽고 유지 관리가 어려울 수 있습니다.
외부 의존성을 조롱하는 것이 좋습니다. 그것은 당신의 신청을 느슨하게 부부가되게 할 것이고 나는 그것이 미래에 더 쉽게 유지 될 것이라고 믿습니다. 또한 테스트가 훨씬 관리하기 쉬울 것입니다.
거기에 많은 Mock Frameworks 당신을 도울 수 있습니다. 나는 당신이 그것을 배우기 전에 약간의 학습 곡선을 가지지 않았다는 것을 인정해야합니다. 그러나 우리는 소프트웨어 개발 사업에 종사하고 있으며 언제나 새로운 것을 배울 수 있습니다.
모의 테스트를 배우기 위해 얼마간 투자하기로 결정한 경우 this article부터 시작할 수 있습니다.
행운을 비네.
두 가지 기술 나는 IO 기반 클래스를 테스트하는 데 유용 발견했습니다
StreamReader 및 Stream보다는 파일 이름과 같은 일반적인 용어로 이야기. 테스트에서 StringReader 또는 MemoryStream을 쉽게 생성하고 그런 식으로 데이터를 제공 할 수 있습니다.Assembly.GetManifestResourceStream을 사용하여 실행시 데이터를 가져옵니다.TrueWill의 조언은 아주 좋은 것 같습니다. 더 큰 작업을 나눌 수 있다면 각 개별 비트에 대한 단위 테스트를 작성하는 것이 일반적 일 것입니다. 데이터베이스 액세스를 제외하고는 일반적으로 쉽지 않을 것입니다.데이터베이스를 가능한 작게 만들 수 있고 시험하기 쉬운 또 다른 클래스의 모든 데이터를 제공하면 삶이 더 쉬워집니다.
시간이 있으면이 부분도 읽는 것이 좋습니다. 왜 중요한지 아이디어를 얻는 데 도움이 될 수있는 테스트에 대한 멋진 이야기 : http://googletesting.blogspot.com/2009/09/it-is-not-about-writing-tests-its-about.html – Juri