테스트가 단위 테스트가 아닌 경우는 언제입니까?

테스트가 단위 테스트가 아닌 경우는 언제입니까?

---

다음과 같은 규칙을 찾고 있습니다.

다음과 같은 경우 테스트는 단위 테스트가 아닙니다.

• 데이터베이스와 통신합니다.
• 다른 테스트와 병렬로 실행할 수 없습니다.
• 레지스트리 또는 파일 시스템과 같은 "환경"을 사용합니다.

또 뭐가 있지?

---

참조 마이클 깃털 '정의를

다음과 같은 경우 테스트는 단위 테스트가 아닙니다.

• 데이터베이스와 통신합니다.
• 네트워크를 통해 통신합니다.
• 파일 시스템과 접촉합니다.
• 다른 단위 테스트와 동시에 실행할 수 없습니다.
• 이를 실행하려면 환경에 특별한 작업 (예 : 구성 파일 편집)을 수행해야합니다.

---

단위 테스트가 아닌 경우 테스트는 단위 테스트가 아닙니다.

진지하게, 그게 전부입니다.

단위 테스트에서 "단위"의 개념은 잘 정의되어 있지 않습니다. 사실 지금까지 찾은 최고의 정의는 원형이기 때문에 실제로 정의가 아닙니다. 단위 테스트의 단위는 가능한 가장 작은 것입니다. 격리 된 상태에서 테스트 할 수 있습니다.

이것은 두 개의 체크 포인트를 제공합니다 : 격리 된 상태에서 테스트됩니까? 그리고 가능한 가장 작은 것입니까?

이 두 가지 모두 상황에 따라 다릅니다. 한 상황 (예 : 전체 객체)에서 가능한 가장 작은 것이 다른 상황에서는 하나의 단일 방법 중 하나의 작은 조각 일 수 있습니다. 그리고 한 상황에서 격리로 간주되는 것은 다른 상황에있을 수 있습니다 (예 : 메모리 관리 언어에서는 가비지 수집기에서 격리 되지 않고 대부분의 경우 관련성이 없지만 때로는 그렇지 않을 수 있음).

---

어설 션이 없으며 예외가 발생할 것으로 예상하지 않습니다.

---

어려운 것 ...

나에게 단위 테스트는 하나의 특정 논리를 분리 하여 확인합니다 . 의미, 나는 몇 가지 논리를 취하고 나머지에서 추출하고 (필요한 경우 종속성을 조롱하여) 다른 종류의 가능한 제어 흐름을 탐색하여 해당 논리 (전체의 단위) 만 테스트합니다.

그러나 다른 한편으로는 ... 우리는 항상 100 % 정확하거나 틀렸다고 말할 수 있습니까 ?? 철학적이지는 않지만 Michael은 자신의 게시물에서 다음 과 같이 말합니다 .

이러한 작업 을 수행 하는 테스트 는 나쁘지 않습니다. 종종 글을 쓸 가치가 있으며 단위 테스트 도구로 쓸 수 있습니다. 그러나 변경 사항이있을 때마다 빠르게 실행할 수있는 일련의 테스트를 유지할 수 있도록 실제 단위 테스트와 분리 할 수 ​​있어야합니다.

그렇다면 내 테스트 폴더의 파일 시스템에서 일부 더미 파일에 액세스하여 예를 들어 xls 파일을 구문 분석하는 논리를 확인하는 단위 테스트를 작성하지 않아야하는 이유는 무엇입니까 (MS 테스트에서 DeploymentItem으로 허용하는 것과 같이)?

물론-언급했듯이-우리는 이러한 종류의 테스트를 다른 테스트와 분리해야합니다 (JUnit의 별도 테스트 스위트에있을 수 있음). 그러나 나는 그 테스트를 거기에 두는 것이 편하다고 느끼면 그 테스트를 작성해야한다고 생각한다 ... 분명히 그리고 항상 유닛 테스트는 단지 한 조각을 따로 테스트해야한다는 것을 기억한다.

내 눈에 가장 중요한 것은 이러한 테스트가 빠르게 실행되고 너무 오래 걸리지 않고 반복적으로 자주 실행할 수 있다는 것입니다.

---

다음과 같은 경우 테스트는 단위 테스트가 아닙니다.

• 한 번에 둘 이상의 것을 테스트합니다 (즉, 두 가지가 함께 작동하는 방식을 테스트합니다)-통합 테스트입니다.

좋은 단위 테스트를위한 체크리스트 :

• 그들은 자동화되어 있습니다
• 그들은 반복 가능하다
• 구현하기 쉽습니다.
• 일단 작성되면 나중에 사용할 수 있도록 남아 있습니다.
• 누구나 실행할 수 있습니다.
• 버튼을 눌러 실행할 수 있습니다.
• 그들은 빨리 달린다

몇 가지 모범 사례 (중요한 순서없이) :

• 테스트는 가능한 한 자주 빠르게 실행될 수 있도록 통합 테스트 (느림)와 분리되어야합니다.
• 너무 많은 논리를 포함하지 않아야합니다 (바람직하게는 제어 구조가 없음).
• 모든 테스트는 한 가지만 테스트해야합니다 (따라서 하나의 assert 만 포함해야 함).
• 어설 션에 사용되는 예상 값은 하드 코딩되어야하며 테스트 런타임에 계산되지 않아야합니다.
• 외부 종속성 (파일 시스템, 시간, 메모리 등)은 스텁으로 대체해야합니다.
• 테스트는 테스트 종료시 초기 상태를 다시 만들어야합니다.
• 어설 션에서는 "엄격히 같음 ..."정책보다는 "포함 ..."정책을 사용하는 것이 좋습니다 (예 : 컬렉션의 특정 값, 문자열의 특정 문자 등).

이것은 내가 Roy Osherove의 책-The Art of Unit Testing 에서 추출한 지식의 일부입니다.

---

실패 할 수있는 여러 단위에 테스트를 구현하는 것은 단위 테스트가 아닙니다.

---

복잡한 질문입니다.

일부 비즈니스 로직을 프로그래밍하고 모든 비즈니스 로직이 어떤 형태의 DAL을 통해 데이터에 도달해야한다고 가정 해 보겠습니다.

Say that for the purposes of testing, I mock the DAL units (by creating "mockingbirds").

But those mockingbirds are of course, additional units in their own right. So even when using mocks, it might seem like I'm still bound to violate the idea of "no other units involved" when I want to unit-test my business logic module.

Of course, it is generally known that "creating mockingbirds for the DAL" can invalidate your very test itself on the count that your mockingbird deviates in some particular aspect from the DAL.

Conclusion : it is outright impossible to do "genuine unit-tests" on business modules that depend in any way on any kind of DAL, question mark ?

Corrolary : the only thing that can possible be ("genuinely" !) unit-tested is the DAL itself, question mark ?

Corrolary of the corrolary : given that the "DAL" is usually either an ORM or the very DML of some DBMS, and given that those products are usually bought as being "proven technology", what is the added value of doing any unit tests what so ever, question mark ?

---

After whether a test is a unit test or not is settled the next question is, is it a good unit test?

참고URL : https://stackoverflow.com/questions/1257560/when-is-a-test-not-a-unit-test