단위 테스트의 경우 클래스 또는 개별 메서드를 테스트하는 것이 더 좋습니다?단위 테스트 클래스 VS 메서드
필자가 본 대부분의 예제는 클래스간에 종속성을 조롱하면서 다른 클래스와 구분하여 클래스를 테스트합니다. 승부를 돌린 또 다른 방법은 테스트하지 않은 메서드를 조롱하는 것입니다 (재정의하여) 한 메서드에서 코드를 테스트하는 것입니다. 따라서 메소드가 서로 분리되어 있기 때문에 1 버그는 1 테스트를 중단합니다.
나는 표준 방법이 있는지, 그리고 클래스를 격리하는 대신 테스트를 위해 각 방법을 격리하는 데 큰 단점이 있는지 궁금해하고있었습니다.
단위 테스트은 하드웨어 시스템 테스트에서 비롯되었으며 소프트웨어에 적용 할 때 다소 의미가 없습니다. 단일 루틴의 격리 테스트부터 메모리없는 데이터베이스를 사용하는 헤드리스 모드의 전체 시스템 테스트까지 모든 분야에 사용할 수 있습니다.
그래서 정의가 컨텍스트와 독립적으로 일을하는 유일한 방법이라는 것을 주장하는 사람을 신뢰하지 마십시오. 다양한 방법이 있으며, 그 중 일부는 때로는 다른 것들보다 유용합니다. 아마도 똑똑한 사람이 주장하는 모든 접근법은 어딘가에서 적어도 어느 정도 가치가 있습니다.
하드웨어의 최소 단위는 원자 또는 일부 원자 입자입니다. 양자 역학의 법칙이 여전히 유지되는지 확인하기 위해 각 원자를 스캔하는 것처럼 일부 사람들은 소프트웨어를 테스트합니다. 다른 이들은 전함을 타고 see if it floats입니다.
중간에 뭔가가있을 가능성이 높습니다. '소프트웨어'를 넘어서서 생산하는 종류의 물건에 대해 알게되면 자신이하고있는 일에 적합한 계획을 세울 수 있습니다.
단위 테스트 포인트는 코드 단위 인 클래스를 테스트하는 것입니다.
이렇게하면 코드의 일부가 예상 한대로 수행되고 있음을 알 수 있습니다.
이것은 테스트 프로세스의 첫 번째 부분이기도합니다. 가능한 한 일찍이 성가신 버그를 잡는 데 도움이되며 단위 테스트를 통해 줄을 더 쉽게 수정할 수 있습니다.
아마도 표준 답변이 하나도 없습니다. 단위 테스트는 개발자를위한 것이며 (또는해야합니다.) 가장 도움이되는 것을하십시오.
개별적인 방법을 테스트하는 한 가지 단점은 개체의 실제 동작을 테스트하지 못할 수도 있다는 것입니다. 일부 방법의 조롱이 정확하지 않아 감지되지 않을 수 있습니다. 또한 모의 작업은 많은 작업이며 테스트를 매우 취약하게 만드는 경향이 있는데, 이는 특정 메서드 호출이 발생하는 것에 대해 테스트가 많은 관심을 보이기 때문입니다.
내 자신의 코드에서 인프라 유형 종속성을 비즈니스 논리와 분리하여 가능하면 모의하지 않고 비즈니스 논리 클래스의 테스트를 작성할 수 있도록 노력한다. 지저분한 레거시 코드 기반을 가지고 있다면, 개별 메소드를 테스트하고 객체의 협업 메소드를 모방 해 서로를 보완하는 것이 더 합리적 일 것입니다.
이론적으로 객체는 응집력이있어 전체를 테스트하는 것이 합리적입니다. 실제로 많은 것들이 특히 객체 지향적이지 않습니다. 어떤 경우에는 공동 작업자가 호출 한 종속성을 조롱하는 것보다 공동 작업자 방법을 모의하는 것이 더 쉽습니다.
단위 테스트는 사용자가 할 수있는 가장 작은 작성 코드를 테스트하는 것입니다. "단위"는 클래스가 아니라 메소드입니다.
모든 공용 메서드에는 적어도 하나의 단위 테스트가 있어야하며, 그 메서드를 구체적으로 테스트해야합니다.
위의 규칙을 따르면 결국 수업 상호 작용이 적용되는 곳으로 이동하게됩니다. 한 가지 방법에 대해 한 가지 시험을 치는 한, 수업 상호 작용도 다루게됩니다.
좋은 답변입니다. 개발자가 무엇을 테스트하는지 결정하는 것은 개발자의 몫입니다. 모니터 옆에 벽에 머리가있는 구멍이 있는지 알지 못해서 수업을 배울 수있었습니다. 이러한 대답과 특히 여러분의 의견을 토대로 볼 때 문제와 개발자가 가장 잘 이해하는 것처럼 보이고 반드시 "더 나은"접근 방식이 필요한 것은 아닙니다. 감사! – Stinky