Playwright .NET의 HTML 비교

사진 제공: Miguel Á Pexels의 Padriñán

사용 중인 언어와 프레임워크가 익숙하지 않은 경우 텍스트(및 해당 HTML) 검사를 자동화하는 것이 어려울 수 있습니다. 학습하고 탐구하는 데 제한된 시간을 갖는 것은 그 자체로 어려운 일입니다. 우리 프로젝트의 연기 테스트를 자동화하기 위한 나의 작업 중 하나는 각 특정 설정에 고유한 환영 메시지가 있는 각 환경의 텍스트를 확인하는 것이었습니다. 그리고 나는 어디서부터 시작해야 할지 확신이 없었다는 것을 인정합니다. 나는 나에게 필요한 것이 무엇인지 알고 그것을 어디서 가져올 수 있는지도 알아냈습니다. 하지만 모든 부품을 하나로 모으는 일은 보기만큼 간단하지 않았습니다.

저는 데이터베이스 액세스가 필요하다는 점에서 시작했습니다. 그런 다음 설정 작업을 통해 애플리케이션 설정(프레임워크에 정보를 찾을 위치를 알려주고 정보를 비공개로 유지하기 위한 구성 설정과 함께 작동)을 사용하여 실행 중에 데이터베이스에 연결할 수 있는지 확인합니다. 그런 다음 조각을 모으고 데이터베이스에서 정보를 가져와 테스트를 위해 표시된 정보와 비교할 수 있었습니다.

수동으로는 간단했습니다. 이것이 제가 바라던 것만큼 쉽지 않을 것이라는 뜻이라고 짐작했어야 했습니다. HTML을 보고 레이아웃이 올바른지 확인하는 것은 간단했습니다. 나는 이것이 단어가 올바른지 확인하고 계속 진행하기 위한 빠른 검사라는 간단한 HTML 레이아웃을 충분히 이해합니다. 제가 수동 검증을 위해 여러 번 일시 중지하면서 이 스모크 테스트를 수행한 이유는 다음과 같습니다. 이 내용과 확인해야 할 사항 목록 사이에서 저는 이 자동화를 성공적으로 수행하기 위해 배우고 탐색하고 도움을 요청하고 이를 다른 테스트에 적용하도록 격려받았습니다.

데이터베이스 액세스(및 적절한 연결 문자열!)가 생성되면 페이지의 텍스트를 변수로 설정할 수 있었습니다. 이것은 쉬운 부분이었습니다. 저는 제가 여기서 무엇을 하고 있는지 알고 있었고 그 일을 해내면서 성취감을 느꼈습니다. 나는 페이지의 텍스트가 단어 단위로 일치하지만 HTML 구성 요소와 일치하지 않을 것이라는 예상을 사용하여 Playwright 테스트를 실행했습니다. 그리고 내 말이 맞았습니다. 적절한 단어가 있었지만 HTML이 추가되어 테스트가 실패했습니다.

연구시간! 첫 번째 시도는 헤더를 포함하여 페이지의 전체 HTML을 가져오는 명령인 Page.ContentAsync()를 사용하는 것이었습니다. 이렇게 하면 텍스트를 검색하고 텍스트의 하위 문자열을 찾을 수 있습니다. 맞나요? 첫 번째 아이디어는 별로 무섭지 않았습니다. 찾고 있던 HTML이 저장되어 있었고, 내가 해야 할 일은 전체 문서 내용을 탐색하여 해당 HTML을 찾는 것뿐이었습니다. 효율적이지 않으며 확실히 좋은 습관도 아닙니다! 필요한 결과를 얻은 다음 반복할 수 있어야 합니다.

그렇지 않았습니다. 전체 페이지에서 하위 문자열을 찾는 것이 빨리 불가능했기 때문에 자동화가 빠르기를 원했습니다. 내가 원했던 대로 작동하도록 하고 비즈니스 규칙을 염두에 두고 이 작업을 수십 번 시도한 후(45분의 노력으로 문제를 해결할 수 없으면 다른 사람에게 물어봐야 합니다), 저는 미팅을 가졌습니다. 개발자 중 한 명. 나는 그들이 바쁘고 매우 필요한 업데이트를 작성하고 있다는 것을 알고 있습니다. 회의는 "필요한 경우 일정을 변경할 수 있습니다"라는 메모가 첨부된 상태로 시작되었습니다.

회의를 기다리는 동안 저는 계속해서 소란을 피웠습니다. 영역을 좁힐 때 어려운 점 중 하나는 div의 클래스였습니다. 이름이 잘 지정되지 않았고 Bootstrap을 사용하면 다음과 같은 div가 중복될 가능성이 있었습니다. 같은 이름으로 인해 다른 페이지에서 문제가 발생했습니다. 나보다 여기에 훨씬 오랫동안 있었던 누군가와 이야기를 나누면서 나는 이것이 항상 페이지의 세 번째 div라는 것을 알게 되었습니다.

이제 나는 그것을 찾기 위한 새로운 계획을 세웠습니다. Nth() 로케이터를 사용하고 올바른 div를 찾으세요. 이 문제를 해결하고 지금 작성 중인 게시물을 작성하고 회의 전에 다음 문제를 진행하고 싶습니다. 많은 분들이 알고 계시거나 의심하실 수 있듯이, 이는 긴급한 일이 발생하도록 하는 좋은 계기가 되었습니다. 계획은 우리가 짝을 이뤄 개발할 때가 될 때까지 며칠 동안 정리함의 페이지에서 페이지로 복사되었습니다.

이 개발자와 함께 일하는 것은 언제나 즐거운 일입니다. 우리는 공통점이 많고 서로를 존중합니다. 보너스로 그들은 가르치는 데 능숙합니다! 목표가 무엇인지 빠르게 검토한 후, 이 문제를 해결하기 위해 제가 시도한 사항을 검토했습니다. 도움이 되길 바라면서 IDE에 오류가 있는 마지막 항목을 남겨두었습니다. 그리고 이제 진전을 이루세요!

디버거를 사용하여 HTML이 올바르게 가져오고 있는지 확인했습니다. 이것은 제가 완전히 확인하지 못한 부분 중 하나였는데, 다행히도 정확했습니다. 우리는 div 이름이 그다지 유용하지 않다는 데 동의했습니다. 최근에 수행한 작업으로 인해 동일한 이름을 사용하지만 다른 페이지에 다른 div가 생성되었습니다. 그것은 언급되었지만 테스트에서 해당 지점에 도달할 때까지 기록되었습니다.

그들이 가지고 있는 NUnit의 기술이 필요했습니다. 이 섹션을 확인하는 더 쉬운 방법은 AreEqual 명령을 사용하는 것이었습니다. 이를 통해 테스트를 통해 문자열이 동일한지 확인할 수 있었습니다. 극작가는 완고했습니다. 문자열보다는 로케이터를 원했고, 그 반대의 경우도 제작하는 데 너무 많은 시간이 걸렸습니다. 그리고 이 기술을 배울 수 있어서 기뻤습니다. 앞으로 이 기술이 유용할 것 같습니다!

Nth()가 작동하도록 몇 번 시도한 후 우리는 페이지에서 이번 한 번만 사용되었는지 확인한 후 이상한 div 클래스를 사용하기로 결정했습니다. 이는 우리에게 출발점을 제공했습니다. 이제 거기에 HTML을 가져오는 방법을 알아내야 합니다(다행히 이것이 해당 특정 div에 있는 유일한 것이었습니다). 몇 번 더 잘못된 시작을 했고 마침내 해당 div에 대한 ContentAsync()가 작동하지 않을 것이라는 생각을 포기하고 제가 시도하고 폐기했던 솔루션으로 안내했습니다.

InnerHtmlAsync()는 div의 정확한 내용을 제공했습니다! 공백과 모든 것. 그리고 그것이 다음 걸림돌이 되었습니다. 그리고 우리는 회의 시간에 도달하지 못했습니다. 고맙게도 그들은 기꺼이 나에게 몇 분 더 시간을 주었습니다. 대부분 이 문제는 이전에 해결했던 문제였기 때문입니다. 공백을 제거하는 구문이 필요했습니다. 궁금하신 경우에는 바꾸기(" ", "")를 사용하세요. 그러면 수동 확인을 위해 추가한 다음 PauseAsync()가 잠시 중지될 때까지 테스트가 실행되었습니다.

그들은 점심을 먹으러 갔고 저는 다음 시간 동안 메모를 준비하는 데 보냈습니다. 찾아야 할 다른 것이 있었는데 이제 어떻게 해야 할지 더 많은 단서가 생겼습니다.

위 내용은 Playwright .NET의 HTML 비교의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!