자동화 된 장치 테스트가 정적 유형 검사를 대체 할 수 있습니까?

Question

나는 전체 단위 테스트/테스트 중심 개발 아이디어를 조사하기 시작했고, 그것에 대해 더 많이 생각할수록 정적 유형 검사와 비슷한 역할을하는 것 같습니다. 두 기술 모두 프로그램의 특정 종류의 오류에 대해 컴파일 타임, 빠른 응답 검사를 제공합니다. 그러나 내가 틀렸다면 나를 수정하지만 전체 커버리지가있는 단위 테스트 스위트는 정적 유형 확인이 테스트 할 모든 것을 테스트 한 다음 일부는 테스트 할 것 같습니다. 또는 다른 방법으로 정적 유형 검사는 프로그램이 정확하다는 것을 "증명"하는 길에만 이동하는 반면, 단위 테스트는 원하는만큼 "증명"할 수 있습니다.

그렇다면 단위 테스트를 사용하는 경우 정적 유형 확인이있는 언어를 사용해야 할 이유가 있습니까? 다소 비슷한 질문이 생겼습니다 여기, 그러나 더 자세히 설명하고 싶습니다. 정적 유형 검사가 단위 테스트를 통해 어떤 구체적인 장점이 있습니까? 컴파일러 최적화 및 Intellisense와 같은 몇 가지 문제가 떠 오르지만 이러한 문제에 대한 다른 솔루션이 있습니까? 내가 생각하지 않은 다른 장점/단점이 있습니까?

Answer 1

자동화 된 장치 테스트가 될 것이라고 생각합니다 중요한 동적 유형 언어에 대해서는 적용하는 상황에서 정적 유형 검사를 대체한다는 의미는 아닙니다. 실제로 동적 타이핑을 사용하는 사람들 중 일부는 실제로 사용하기 때문에 사용하고있을 수 있습니다. ~ 아니다 일정한 유형 안전 점검의 번거 로움을 원합니다.

정적 유형 언어에 비해 동적으로 타이핑 된 언어가 제공하는 장점은 테스트를 넘어서고 유형 안전은 단지 한 가지 측면 일뿐입니다. 동적 및 정적 유형 언어에 대한 프로그래밍 스타일과 디자인 차이도 크게 다릅니다.

게다가, 유형 안전성을 너무 적극적으로 시행하는 단위 테스트는 결국 소프트웨어를 동적으로 입력해서는 안된다는 것을 의미합니다. 또는 적용되는 설계는 역동적 인 언어가 아니라 정적으로 입력 한 언어로 작성되어야합니다.

Answer 2

소프트웨어 품질에 대한 불변의 사실이 있습니다.

컴파일 할 수 없다면 배송 할 수 없습니다

이 규칙에서 정적으로 입력 한 언어는 동적으로 입력 한 언어를 이길 것입니다.

네, 그렇습니다.이 규칙은 불변이 아닙니다. 웹 앱은 컴파일없이 배송 할 수 있습니다 (컴파일하지 않은 많은 테스트 웹 앱을 배포했습니다). 그러나 근본적으로 진실한 것은

오류를 빨리 잡을수록 더 싼 것입니다.

정적으로 입력 한 언어는 소프트웨어 개발주기에서 가능한 초기의 순간 중 하나에 실제 오류가 발생하는 것을 방지합니다. 역동적 인 언어는 그렇지 않습니다. 단위 테스트, 슈퍼 인간 수준에 철저한 경우 정적으로 입력 한 언어를 대신 할 수 있습니다.

그러나 왜 귀찮게합니까? 컴파일러 형태로 전체 오류 확인 시스템을 작성하는 엄청나게 똑똑한 사람들이 많이 있습니다. 오류가 더 빨리 발생하는 것이 걱정된다면 정적으로 입력 한 언어를 사용하십시오.

이 게시물을 동적 언어의 강타로 받아들이지 마십시오. 나는 매일 다이나믹 언어를 사용하고 사랑합니다. 그것들은 엄청나게 표현력이 풍부하고 유연하며 엄청나게 팬 스케인 한 프로그램을 허용하지만, 초기 오류보고의 경우 정적으로 입력 한 언어를 잃어 버린다는 사실.

Answer 3

합리적인 크기의 프로젝트의 경우 단위 테스트만으로 모든 상황을 설명 할 수는 없습니다.

따라서 내 대답은 "아니오"이며, 모든 상황을 설명하더라도 처음에는 역동적 인 언어를 사용하는 전체 목적을 물리 쳤습니다.

유형-안전을 프로그래밍하려면 유형-안전 언어를 더 잘 사용하십시오.

Answer 4

100% 코드 적용 범위가 있다고해서 응용 프로그램을 완전히 테스트했음을 의미하지는 않습니다. 다음 코드를 고려하십시오.

if (qty > 3)
{
    applyShippingDiscount();
}
else
{
    chargeFullAmountForShipping();
}

Qty = 1 및 Qty = 4의 값으로 펌핑하면 100% 코드 적용 범위를 얻을 수 있습니다.

이제 내 사업 조건이 "... 3 개 이상의 품목을 주문하기 위해 배송비에 할인을 적용하는 것"이라고 상상해보십시오. 그런 다음 경계에서 작동하는 테스트를 작성해야합니다. 그래서 수량이 2,3과 4 인 테스트를 설계 할 것입니다. 여전히 100% 커버리지가 있지만 더 중요한 것은 논리에서 버그를 발견했습니다.

그리고 이것이 코드 커버리지에만 초점을 맞춘 문제입니다. 기껏해야 당신은 개발자가 비즈니스 규칙을 기반으로 초기 테스트를 만드는 상황으로 끝납니다. 그런 다음 커버리지 번호를 높이기 위해 새로운 테스트 케이스를 설계 할 때 코드를 참조합니다.

Answer 5

매니페스트 타이핑 (내가 의미한다고 생각하는)은 사양의 한 형태이며, 단위 테스트는 예제 만 제공하기 때문에 훨씬 약합니다. 중요한 차이점은 사양이 어떤 경우에도 보유 해야하는 것을 선언하고 테스트는 예제 만 포함한다는 것입니다. 테스트가 모든 경계 조건을 다루는 것을 확신 할 수 없습니다.

사람들은 또한 선언 된 유형의 가치를 문서로 잊어 버리는 경향이 있습니다. 예를 들어 Java 메소드가 반환하는 경우 a List<String>, 나는 내가 얻는 것을 즉시 알고, 문서, 테스트 케이스 또는 메소드 코드 자체를 읽을 필요가 없습니다. 유사하게 매개 변수의 경우 : 유형이 선언되면 메소드가 무엇을 기대하는지 알고 있습니다.

로컬 변수의 유형을 선언하는 값은 잘 작성된 코드에서는 변수의 존재 범위가 작아야하기 때문에 훨씬 낮습니다. 그러나 여전히 정적 타이핑을 사용할 수 있습니다. 컴파일러가 유추하도록 유형을 선언하는 대신에 유형을 선언하는 대신에 유형을 선언하는 대신에 사용할 수 있습니다. 같은 언어 스칼라 또는 씨# 이 일을 할 수 있습니다.

테스트의 일부 스타일은 사양에 가까워집니다. 빠른 확인 또는 스칼라 변형입니다 스칼라 크 중요한 경계를 추측하려고 시도하는 사양에 따라 테스트를 생성합니다.

Answer 6

나는 그것을 다른 방식으로 말할 것입니다-당신이 정적으로 유형 된 언어가 없다면 더 나은 해당 코드로 "실제"를 수행 할 계획이라면 매우 철저한 단위 테스트를 받으십시오.

즉, 정적 타이핑 (또는 명시 적 타이핑)은 단위 테스트보다 일반적으로 선호하는 몇 가지 중요한 이점이 있습니다. 훨씬 더 이해하기 쉬운 API를 생성하고 동적으로 유형 된 언어로 훨씬 어려운 방식으로 응용 프로그램의 "골격"(즉, 각 모듈 또는 코드 섹션)을 빠르게 볼 수 있습니다.

요약하자면, 견고하고 철저한 단위 테스트를 감안할 때, 동적으로 유형 된 언어와 정적으로 유형 된 언어 사이의 선택은 대부분 맛 중 하나입니다. 어떤 사람들은 하나를 선호합니다. 다른 사람들은 다른 것을 선호합니다. 작업에 적합한 도구를 사용하십시오. 그러나 이것은 그들이 동일하다는 것을 의미하지는 않습니다. 정직한 언어는 항상 특정 방식으로 우위를 가질 것이며 동적으로 유형 된 언어는 항상 특정 방식으로 우위를 가질 것입니다. 단위 테스트는 동적 인 언어의 단점을 최소화하는 데 먼 길을 가지지 만 완전히 제거하지는 않습니다.

Answer 7

아니.

그러나 이것이 가장 중요한 질문이 아닙니다. 가장 중요한 질문은 다음과 같습니다.

정적 유형 검사의 목적을 고려하십시오 : 코드 결함 클래스 (버그)를 피하십시오. 그러나 이것은 모든 코드 결함의 더 큰 영역의 맥락에서 무게를 측정해야합니다. 가장 중요한 것은 좁은 은색을 따라 비교하는 것이 아니라 코드 품질의 깊이와 폭을 가로 지르는 비교, 올바른 코드 작성의 용이성 등입니다. 정적 유형 확인없이 더 효율적으로 코딩하면 그만한 가치가 있습니다. 테스트에 구멍이있는 경우 정적 유형 검사가 잡을 수있는 경우에도 마찬가지입니다.

Answer 8

나는 당신이 매우 철저하다면 그것이 가능하다고 생각합니다. 하지만 왜 귀찮게합니까? 언어가 정적 유형이 올바른지 확인하기 위해 이미 점검 중이라면, 테스트 할 때는 아무런 의미가 없습니다 (무료로 받기 때문에).

또한 IDE가있는 정적 유형 언어를 사용하는 경우 IDE는 테스트하기 전에도 오류와 경고를 제공 할 수 있습니다. 동일하게 수행 할 수있는 자동화 된 장치 테스트 응용 프로그램이 있는지 확실하지 않습니다.

Answer 9

역동적이고 늦은 바인딩 언어의 모든 이점을 감안할 때, 이것이 단위 테스트에서 제공하는 가치 중 하나라고 생각합니다. 여전히 신중하고 의도적으로 코딩해야하지만 모든 종류의 코딩 IMHO에 대한 #1 요구 사항입니다. 명확하고 간단한 테스트를 작성하면 디자인의 명확성과 단순성과 구현을 증명하는 데 도움이됩니다. 또한 나중에 코드를 보는 사람들에게 유용한 단서를 제공합니다. 그러나 나는 불일치 한 유형을 감지하는 데 의존하지 않을 것이라고 생각합니다. 그러나 실제로 나는 유형 확인이 실제로 많은 실제 오류를 포착한다는 것을 알지 못합니다. 처음부터 명확하고 간단한 코딩 스타일이 있다면 실제 코드에서 발생하는 오류 유형이 아닙니다.

JavaScript의 경우 JSLINT가 거의 모든 유형 확인 문제를 찾을 것으로 예상됩니다. 주로 노출을 줄이기 위해 대체 코딩 스타일을 제안함으로써.

Answer 10

유형 확인은 계약 시행에 도움이됩니다 ~ 사이 시스템의 구성 요소. 단위 테스트 (이름에서 알 수 있듯이)는 내부 구성 요소의 논리.

단일 코드 단위의 경우, 단위 테스트는 실제로 정적 유형을 불필요하게 확인할 수 있다고 생각합니다. 그러나 복잡한 시스템에서 자동화 된 테스트는 시스템의 다른 구성 요소가 상호 작용할 수있는 모든 다수의 방법을 확인할 수 없습니다. 이를 위해 사용 인터페이스 (어떤 의미에서, 구성 요소들 사이의 일종의 "계약")는 잠재적 오류를 줄이는 데 유용한 도구가됩니다. 인터페이스에는 컴파일 타임 유형 확인이 필요합니다.

나는 역동적 인 언어로 프로그래밍을 정말 좋아하기 때문에 역동적 인 타이핑을 강타하지 않습니다. 이것은 최근에 나에게 일어난 문제 일뿐입니다. 불행히도 나는 크고 복잡한 시스템에 동적 언어를 사용한 경험이 없으므로이 문제가 실제인지 이론적인지 다른 사람들의 의견에 관심이 있습니다.