최근에 단위 테스트에 대해 많이 들었습니다.CRUD 응용 프로그램 테스트 단원?
내가 이해하려고하는 점은 cruddy 비즈니스 앱을 테스트하는 방법에 대해 어떻게 생각 하나? (기본적으로 데이터베이스에 데이터를 쓰거나 데이터베이스에서 데이터를 읽는 앱).
단위 테스트는 해당 시나리오에서 가치가 있습니까? 아니면 일반적으로 더 복잡한 작업을 단위 테스트합니까? 하나의 방법을 더 이상 -
감사
단위 테스트 코드의 개별 단위 테스트에 관한 것입니다.
CRUD에 들어가는 순간, 네트워크, IO, 데이터베이스 및 다른 것들을 테스트하는 것에 대해 이야기하고 있습니다. 이는 단위 테스트가하는 것 이상입니다. 이 경우 이것을 통합 테스트라고합니다 (코드가 다른 코드/시스템과 통합되는 방식을 테스트하는 중입니다).
소프트웨어 프로젝트, CRUD 응용 프로그램에서든 두 가지 유형의 테스트 (및 기타 유형 - 회귀, 성능 등 ...)가있는 곳이 있습니다.
단위 테스트는 여러 가지 SUT (테스트중인 시스템)를 테스트 할 수 있습니다. 두 가지 방법 또는 클래스 묶음입니다. 단위 테스트의 차이는 매우 희미하며 단위 테스트 또는 통합 테스트의 SUT 크기와 속성에 대한 명확한 정의가 없습니다. –
@ Yauheni Sivukha - 위키 백과 : 단위는 응용 프로그램에서 가장 작은 테스트 가능한 부분입니다. http://en.wikipedia.org/wiki/Unit_testing – Oded
@Odded - Wikipedia는 테스트 할 수있는 가장 작은 부분이 방법이라고 말하지 않습니다. 상황에 따라 다릅니다. 테스트가 합계를 순서대로 확인하면 주문 행을 채워야합니다. 그건 그렇고 : http://stackoverflow.com/questions/10752/what-is-the-difference-between-integration-and-unit-tests –
단위 테스트는 기능에 대한 간단한 간단한 테스트입니다. 일반적으로 모든 CRUD 기능을 처리 할 응용 프로그램의 데이터 계층을 단위 테스트합니다. 만들기 및 검색에 대한 테스트는 다음과 같을 수 있습니다.
모든 응용 프로그램이 CRUD 인 경우 단위 테스트에서 아무런 의미가 없습니다. 이제 값이 DB에서 나오거나 검증되기 전에 어떤 종류의 비즈니스 로직이 있다면 그렇습니다. 단위 테스트를 만드는 것이 좋습니다. CRUD 부분 테스트는 IMO 단위 테스트에 속하지 않습니다.
Cruddy apps 드물게 cruddy. 결국 비즈니스 개체 계층을 포함하도록 성장합니다.
그래서, 저는 단위 테스트를 할 것입니다. 기본 cruddy 앱조차도 상호 작용 레이어, 데이터 액세스 레이어 및 엄청나게 단순한 UI로 분할되어야합니다 (모든 UI 상태는 상호 작용 레이어에 유지되어야 함). 결국 상호 작용 및 데이터 액세스 계층 사이에 비즈니스 객체 계층을 가져올 수 있습니다.
모든 사람들이 테스트 첫 번째로 모든 것을 설계해야하는 방법에 대해 계속해서 알고 있지만 더 복잡한 문제를 테스트하는 단위를 사용하는 경향이 있습니다.
내 규칙에 따라 내가 실제로 레 구레 티에 부러 뜨릴 것으로 예상되는 것들에 대한 자동화 된 테스트를 만들거나 내가 즉시 알지 못하는 것들이 깨졌습니다. 그리고 무엇보다, 나는 스스로 시험 할 수없는 것들을 시험하고 싶습니다.
예를 들어, "47 개의 다른 변수를 사용하여 큰 복잡성을 계산하십시오"모듈에는 좋은 코드 적용 범위를 달성하고 shoudl이 가능한 모든 코드 경로를 처리하는 테스트가 있어야하지만 그 결과를 전체 코드 경로로 다시 저장하는 코드가 필요합니다. 데이터베이스가 반드시 테스트를 필요로하지는 않습니다. 특히 간단한 CRUD 작업을 수행하는 경우에 특히 그렇습니다.
또한 자동화 된 UI 테스트 (WatiN 또는 비슷한 것을 사용하여)를 사용하여 내 사이트의 회귀 테스트를 작성하므로 일부 핵심 구성 요소를 변경할 때 내가 확인하지 않았 음을 확인하기 위해 정상 체크를 실행할 수 있습니다. 사이트의 모서리를 날려 버리십시오.
결국 ROI에 관한 것입니다. 얼마나 많은 시간을이 일에 집어 넣고, 얼마나 빠져 나오고 있습니까?단위 테스트가 CRUDy 비즈니스 앱의 일부 바보 데이터 액세스 레이어에서 100 % 코드 범위에 도달하면 평범하고 단순한 시간과 고용주의 돈을 낭비하게됩니다. 그러나 로켓이나 의료 장비를 제작하거나 QA 부서를위한 자원이없는 두 곳의 상점이라면 많은 단위 테스트를 통해 많은 시간과 돈, 그리고/또는 생명을 구할 수 있습니다 .
test-first는 단위 테스트에 관한 것이 아닙니다. TDD (또는 BDD to some)라는 디자인 방법론에 관한 것입니다. – Oded
Test everything that could possibly break.
물론 데이터 지향 응용 프로그램이있는 경우 CRUD 작업을 테스트해야합니다. 그리고 내 expirience에서 그러한 종류의 테스트는 매핑, 저장 프로 시저 논리, 데이터 모델의 실수, 잘못된 데이터 등에서 많은 버그를 발견 할 수 있기 때문에 이러한 테스트는 매우 유용한 테스트입니다.
그래서이 응답에서 이해할 수있는 것은 무엇입니까? 테스트 데이터베이스에서 읽기/쓰기 테스트를해서는 안됩니다. 비즈니스 로직 코드를 테스트해야합니다. – foreyez
가능성이있는 모든 것을 테스트하십시오. 이것은 일반적인 의미입니다. –