itsource

(Angularj) 웹 어플리케이션 통합 테스트 방법

mycopycode 2023. 3. 23. 22:43
반응형

(Angularj) 웹 어플리케이션 통합 테스트 방법

웹 앱을 개발 중입니다.그것은 두 부분으로 구성되어 있다.노드레스트 서버 및 angularjs 클라이언트.

앱의 구성은 다음과 같습니다.Rest Server <--> API Module <--> Angular App

서버는 현재 정상적으로 테스트되고 있습니다.유닛 테스트와 통합 테스트가 있습니다.Integration Tests는 실제 데이터베이스에 액세스하여 http를 통해 나머지 api를 호출합니다.서버 테스트에 사용할 수 있는 수준이라고 생각합니다.통합 테스트도 빠르게 실행됩니다.서버를 테스트한 방법은 사용 사례에 충분하다고 확신하며 결과에 만족합니다.

하지만 angularjs 앱을 테스트하는 방법을 고민하고 있습니다.관련 지침과 모듈에 대한 유닛 테스트가 있습니다.이걸 쓰는 건 문제가 되지 않았어요

사용자 시나리오를 커버하는 통합 테스트를 작성하고 싶습니다.가입 시나리오와 같은 경우:사용자는 웹사이트에 접속하여 등록 양식에 접속하여 데이터와 함께 양식을 제출합니다.

앵글제스 팀은 ng-시나리오에서 영사기로 이동하고 있습니다.프로젝터는 셀레늄을 테스트에 사용하고 있습니다.이 때문에, 다음의 2개의 스코프가 있습니다.앱 범위와 테스트 범위.

이제 사용할 수 있는 추상화 세 가지가 생각납니다.그리고 어떤 게 나한테 가장 잘 어울리는지 모르겠어.

  • API 모듈 모킹
  • 나머지 서버 모킹
  • 풀 서버 사용

API 모듈 모킹

이 경우 서버를 설정할 필요가 없습니다.브라우저에서 모든 상호 작용이 실행 중입니다.

장점:

  • 서버가 필요 없음

단점:

  • api는 브라우저 범위 내에 있으며, 저는 이것을 수정해야 합니다.

저는 이 솔루션을 매우 좋아하지만 API를 조롱하기는 어렵습니다.브라우저 범위에서 API를 수정해야 합니다.따라서 테스트에서 브라우저로 수정 내용을 보내야 합니다.이건 할 수 있지만 어떻게 이런 주장을 할 수 있는지 모르겠어요mockedApi.method.wasCalledOnce() scope에서

나머지 서버 모킹

장점:

  • 클라이언트는 변경되지 않습니다.
  • 처리할 수 있는 범위는 1개뿐

단점:

  • 나머지 경로를 설정해야 합니다.

nodejs에 한 Mock Rest Server를 할 수 .프로젝터 테스트는 nodejs로 작성되므로 테스트에서 서버 제어를 수행할 수 있습니다.테스트를 실행하기 전에 서버에 대응 방법을 지시할 수 있습니다.거 있잖아요.server.onRequest({method: 'GET', url: '/'}).respondWith('hello world')

'아저씨'와 같은 할 수 있어요.wasCalledOnce

데이터베이스와 함께 전체 서버 사용

각 테스트는 완전한 서버에서 실행되며 데이터베이스에 요소를 추가할 수 있습니다.각 테스트가 끝나면 데이터베이스 내의 예상 요소를 확인할 수 있습니다.

장점:

  • 이러한 테스트가 실행 중인 경우 테스트된 사용 사례에서 앱이 작동한다는 것은 확실합니다.

단점:

  • 나머지 서버와의 통합 테스트는 이미 완료했습니다.이거 또 똑같은 느낌이야.
  • 셋업은 풀서버에 의존합니다.

현재의 결론

  • API를 조롱하면 서버와 클라이언트가 완전히 분리됩니다.
  • Mock API를 사용하는 것은 더 높은 수준의 테스트이지만 가짜 서버가 필요합니다.
  • 완전한 통합 테스트를 실시하면 최고의 신뢰성을 얻을 수 있지만, 이 또한 서버 코드에 크게 의존합니다.

뭘 골라야 되지?어떻게 하실 생각이세요?

내 생각에 나는 익트랙터 구글 그룹에서 이 같은 질문에 답한 것 같다.서버를 필요로 하지 않고 모든 테스트 코드를 한 곳에서 (프로트랙터에) 보관하고, Protractor와 브라우저 간에 분할하지 않는 것에 대해서는 당신과 거의 같은 생각입니다.이것을 가능하게 하기 위해서, 저는 스스로 문제를 해결하고, 프로젝터내에서 동작하는 $httpBackend 서비스의 프록시를 개발했습니다.$httpBackend 서비스를 Protractor에서 실행 중인 것처럼 설정할 수 있습니다.꽤 오랫동안 작업해 왔는데, 이 시점에서 꽤 풀한 것이 특징입니다.제가 뭔가 중요한 것을 빠뜨린 것이 있으면 봐 주시면 감사하겠습니다.

https://github.com/kbaltrinic/http-backend-proxy

이것은 특별한 도구와는 무관한 훌륭한 질문입니다.큰 "그린필드" 프로젝트에서도 같은 문제에 직면해야 했습니다(즉, 처음부터 다시 시작해야 했습니다.

여기에는 어휘의 문제가 있습니다. "mock"이라는 단어는 어디에서나 사용되고 있으며, "integration test"라고 하는 것은 보다 "완전 엔드 투 엔드 자동 기능 테스트"입니다.악의는 없습니다. 다만 명확한 표현이 문제를 해결하는 데 도움이 될 것입니다.

실제로 정답을 제안하셨습니다.#2 stub 나머지 서버입니다.#1은 선택 가능하지만 곧 개발과 유지보수가 어려워질 것입니다.#3은 훌륭한 아이디어이지만 UI 테스트 및 UI 검증과는 관계가 없습니다.

프런트 엔드의 높은 신뢰성을 실현하기 위해서는 백엔드와는 독립적으로 나머지 서버를 스텁하기만 하면 됩니다.즉, 1개의 http 요구에 항상 같은 응답을 할 수 있는 멍청한 심플 REST 서버를 개발하면 됩니다.Idempotence 원칙을 지키면 개발과 테스트가 다른 어떤 옵션보다 매우 쉬워집니다.

그 후, 1개의 테스트에서는, 화면에 표시되는 것(상단 테스트)과 서버에 송신되는 것(하단 테스트)만을 체크해, 풀 UI 스택을 1회만 테스트합니다.

질문에 대한 완전한 답변은 블로그 기사 전체를 볼 가치가 있지만, 제가 제안하는 것을 통해 여러분이 어떻게 해야 할지 느낄 수 있기를 바랍니다.

안부 전합니다

다음은 Angular 코드에 대한 통합 테스트를 작성하는 방법입니다.주요 개념은 UI가 소비하는 방식과 매우 유사한 방식으로 다양한 기능을 호출할 수 있도록 코드를 구성하는 것입니다.단, 이 경우 코드를 적절히 분리하는 것이 중요합니다.

자세한 사항은 이쪽:http://www.syntaxsuccess.com/viewarticle/angular-integration-tests

좋은 질문입니다.저는 이렇게 하겠습니다.

관련 지침 및 모듈에 대한 각도 단위 테스트가 이미 완료되었으므로 이 테스트는 완벽합니다.

또 하나 완벽한 것은 서버 Integration Tests가 실제 데이터베이스에 액세스하고 있으며, 또한 http를 통한 나머지 api가 동작하고 있는지 확인하는 것입니다.

따라서 Angular 및 서버를 동시에 포함하는 고급 통합 테스트를 추가하는 것이 좋습니다.

조롱을 피할 수 있다면 가능하면 작업을 저장하여 추가 코드를 유지하십시오.

좋은 읽을거리: http://blog.ericbmerritt.com/2014/03/25/mocking-is-evil.html

REST 서버를 조롱하는 것이 가장 좋고 깨끗한 선택이라고 생각합니다.Mountebank(http://www.mbtest.org)를 사용해 보십시오.뛰어난 가상화 서비스 툴.

언급URL : https://stackoverflow.com/questions/19078962/how-to-do-integration-testing-for-angularjs-web-apps

반응형