요즘 나는 Java로 데이터 구조를 코딩하고 있습니다. 그들 중 많은 수가 (전부는 아닐지라도) 매우 간단한 인터페이스 (add, contains, delete)를 제공하지만, 사소한 알고리즘은 중요하지 않습니다.tdd (평범하지 않은 알고리즘 사용)
그런 상황에서 어떻게 tdd 기법을 사용할 수 있습니까?
제가 생각하기에는 tdd (및 일반적으로 단위 테스트)는 인터페이스가 아니라 구현을 테스트하는 것입니다. 내가 맞습니까? 이 문제를 어떻게 처리 할 수 있습니까?
이 사례를 처리 할 수있는 방법을 알고 있다면 알려 주시기 바랍니다.
도움 주셔서 감사합니다.
TDD가 구현이 아닌 인터페이스를 테스트하는 것이 맞습니다. 그렇다면 실제 구현을 테스트하는 것이 왜 중요합니까? 요점은 인터페이스를 충분히 테스트하면 구현 은과 상관 없다는 것입니다.
구현에서 버그를 발견하면 외부 세계에 노출 된 인터페이스를 어딘가에 위배한다는 것을 의미합니다. 인터페이스를 위반하는 위치까지 추적해야합니다. 그것이 테스트 케이스를 작성하는 곳입니다.
인터페이스 테스트는 구현 테스트보다 훨씬 우수합니다. 나중에 구현을 리팩토링하면 테스트는 유효합니다.
단위 테스트가 너무 복잡하여 코드를 리팩터링하고 별도로 테스트 할 수있는 몇 가지 작은 (잠재적으로 개인적인) 방법으로 분류해야한다는 것을 알 수 있습니다.
(잠재적으로 개인)를 제외하고 동의합니다 : 원본 클래스에서 사용되는 다른 클래스의 public 메소드. –
@WW : 이것은 확실히 고려해야 할 옵션입니다. 제 생각에는 새로운 방법이 얼마나 재사용 가능한지에 달려 있다고 생각합니다. 그것이 다른 곳에서 유용 할 잠재력이 있다면, 그것을 다른 반에 공개하십시오. 그렇지 않은 경우 비공개로 설정합니다. 포스터의 첫 번째 본능은 하나의 긴 방법을 쓰는 것이었기 때문에 다른 곳에서는 가치가별로 없다고 가정했습니다. 그러나 리팩토링 할 때 다시 평가해야한다는 데 동의합니다. – dbyrne
구현에 몇 가지 제한 사항 (예 : 비교 횟수, 실적 등)이 있는지 테스트하려면 테스트를 사용하여 이러한 제약 조건을 TDD 할 수 있습니다. http://twitoaster.com/kentbeck/brunopedroso-i-think-you-could-tdd-quicksort-youd-need-assertions-about-the-of-comparisons-ways-to-incrementally-improve-the-count/
그것은이 아이디어에 대해 이야기 : 빠른 종류의 TDDing
나는 매우 통찰력이 트위터 대화를 발견했다. 우리는 퀵 정렬이 버블 정렬보다 빠릅니다. 두 알고리즘 모두 동일한 출력 (정렬 된 콜렉션)을 제공하지만 제약이 다릅니다.알고리즘의 제약 조건을 테스트에 명시 적으로 추가합니다 (알고리즘이 예상 한대로 작동하는지 분명히 테스트해야 함).
나는이 예에서 이미 답을 알고 있다는 것을 알고있다. 그러나 복잡한 알고리즘을 찾아야하는 경우 TDD로 끝내지 않을 것입니다. 그러나 테스트 및 제약 테스트를 통해 답을 찾았는지 알 수 있습니다.
좋은 생각 인 것 같습니다. 구현의 세부 사항을 너무 신경 쓰지 않고 알고리즘을 테스트합니다. 그게 최선의 코딩 방법이라고 생각하니? – TheSENDER
솔직히 말해서, 이러한 유형의 알고리즘을 코딩해야 할 때, 나는 보통 테스트를 작성하여 작동하는지 확인합니다. 개선 할 필요가 있고 개선해야한다는 생각이들 때 프로파일을 작성한 다음 주로 성능에 대한 테스트를 작성합니다. 나는 링크에 게시 한 방식으로 알고리즘을 구현 한 적이 없지만 작동 할 수 있습니다. 그러나, 나는 혁명적 인 알고리즘이 이런 방식으로 발견 될 수 있다고 생각하지 않는다. 당신은 강력한 수학적 배경이 필요합니다. 테스트는 도움이 될만한 것이지, 효과를 내지 못하는 것입니다. –
죽은 링크가되었습니다. 나는 내 전화에있어. 아니면 고칠 수있어. :) –
RSpec 책의 TDD/BDD 예제가 매우 유용하다는 것을 알았습니다. http://www.pragprog.com/titles/achbd/the-rspec-book 이것은 레일스가 지향하는 것일 수도 있지만 저자가 문제를 정의한 것에서부터 복잡한 케이스에 이르는 직관적 인 테스트 케이스를 식별하는 데 도움이 될 수 있습니다. 방법. 이 책의 예제는 게임을 개발하고 모든 테스트를 통과하기위한 진행 상황에 대해 설명합니다.
또한 인터페이스에 대해 이야기하고 BDD가 응용 프로그램 동작 (예 : 알고리즘)을 테스트하기 때문에 유용 할 수 있습니다.
구현이 복잡한 경우 작은 모듈로 나누는 것이 좋습니다. 이 작은 모듈들은 자신 만의 인터페이스를 가지고 있습니다. 예를 들어 깊이 우선 검색을 통해 Sudoku를 해결한다면 깊이 우선 검색 알고리즘과 Sudoku 위치 열거 알고리즘을 별도로 개발하는 데 비용을 지불하게됩니다. 나는 얼마 전 이것에 대해 블로깅했다 : http://matteo.vaccari.name/blog/archives/416
이 경우 인터페이스 만 테스트하면 수업을 만들고 필기 방법을 쓰는 데 도움이되지 않는다. 실제로는 tdd의 이점을 무효화한다. 생각하지 않니? – TheSENDER
'merge()'나'resizeArray()'와 같은 내부 구현 메소드에 대한 테스트를 작성하는 것을 막을 수는 없지만, 이렇게하면 테스트가 더 부서지기 쉽다. –
또한 테스트가 동일한 패키지에 있음을 보장하는 경우, "실제"세계에 여전히 숨겨져있는 것을 보호함으로써이를 수행 할 수 있습니다. –