2012-03-15 7 views
0

저는 C# 및 UI 개발자이며 단위 테스트을 VS CodedUI for ASP.NET 웹 응용 프로그램에 작성하는 데 관심이 있습니다. 내가 본 적이있는 대부분의 사용법은 통합 테스트입니다. 실제 웹 페이지를 가리키고 일부 단계를 실행하고 출력을 테스트하는 테스트를 작성합니다. 좀 더 작고 세분화 된 것을 원한다. 개발자를 위해 간단하다. (읽기 : lazy : P).VS 코딩 UI - 실제 단위 테스트

내 현재 설정은 다음과 같습니다 등, 페이지, 컨트롤, 자바 스크립트를 포함,

  • 웹 응용 프로그램
  • 웹 응용 프로그램은 또한 테스트 페이지 포함 - 마크 업에 단일 사용자 제어가 포함 된 페이지를, 코드 숨김에 일부 하드 코딩 된 데이터가 포함되어 있습니다.
  • 테스트 페이지를 시작하고 테스트를 실행하고 출력을 어설 션하는 CodedUI 프로젝트입니다.

이것은 좋은 시작이지만 개선하기 위해 찾고 있습니다.

(첫 번째 ...) 문제는 테스트 데이터와 테스트 단계가 각각 다른 위치에 있다는 것입니다. 웹 응용 프로그램과 codedUI 프로젝트 각각에 있습니다. 일반적인 개발자 유닛 테스트에서는 데이터를 설정하는 코드를 작성한 다음 다른 모든 작업을 수행하므로 필요한 모든 것이 한 위치에 있습니다. 셋업을 통해 테스트 실패를 본 사람은 테스트와 테스트중인 페이지를 모두 알아야합니다.

내가 가진 몇 가지 아이디어, 왜 그들은 빨아 :

  1. 가 codedUI 프로젝트에서 테스트 페이지를 넣습니다. 이는 몇 가지 이유로 인해 문제가됩니다. 사용자 컨트롤을 쉽게 테스트 할 수는 없지만 제 스톱 포인트 였지만 다른 것들도 많이 있다고 생각합니다.
  2. 데이터를 제공하는 테스트 페이지에 쿼리 문자열을 전달하십시오. 이것은 끔찍한 아이디어가 아니지만 신속하게 다루기 힘들 수 있습니다.
  3. 테스트 데이터가 포함 된 테스트 페이지에서로드 할 공용 클래스를 전달하십시오. 이를 위해서는 테스트 페이지에 테스트 프로젝트에 대한 참조가 있어야합니다. 이는 좋지 않습니다.
  4. codedUI 테스트에서 테스트 페이지를 동적으로 작성하고 컴파일하십시오. 나는 이것으로 시작하고 싶지도 않다.
+0

지금까지 옵션 # 2를 사용하여 테스트 자체에 가장 근접한 테스트 데이터를 제공하는 가장 좋은 방법을 제공했습니다. 그러나 문제는 쿼리 문자열의 길이가 제한되어 있고 현재 테스트가 실행되지 않아도 미래의 쿼리가 확실히 실행된다는 것입니다. – rythos42

답변

0

외부 데이터로 웹 페이지를 테스트하는 단위에 대해 이야기하고 있다고 가정 해 보겠습니다. CUIT를 사용하면 data driven CUIT으로 할 수 있습니다.

+0

나는 그것을 좋아하지 않는다. 그것은 "자동화"테스트이고, "단위"테스트는 아닙니다. 나는 테스트 데이터가 테스트가 쓰여지고있는 곳에서 직접 볼 수 있기를 원한다. – rythos42