커서와 클로드를 사용하여 극작가와 함께 자동화된 테스트를 만드는 부분

1부 링크

4부

이 프로젝트의 Github 소스 코드 저장소는 다음과 같습니다: https://github.com/joegiglio/cursor2-kb

오랜만이네요…

저번에 얘기했을 때 커서가 고장나는 것 같았고 파일 구조의 인덱스가 손상된 것 같았습니다. 수정을 위해 23일을 기다린 후, 문제가 마침내 해결된 것 같다고 보고하게 되어 기쁩니다! UI는 여전히 이상하고 잠시 후 일종의 메모리 누수로 인해 속도가 느려지는 것 같습니다. 이는 다시 시작하면 해결될 수 있습니다. 그러나 적어도 지금은 올바른 파일을 변경하고 있으며 이상하게 손상된 파일 인덱스에 직면하지 않습니다.

수정을 기다리는 동안 많은 Cursor 사용자들이 Cursor 및/또는 Claude의 불안정성에 대해 불만을 토로하고 있는 것을 발견했습니다. 예, 때로는 작동하고 작동할 때 인상적이지만 움직이는 부품의 블랙박스, 이면의 지속적인 업데이트 및 일관되지 않은 결과입니다.

헬프 데스크 프로젝트를 옆으로 치우기로 결정하고 대신 지식 기반 애플리케이션을 구축할 수 있는지 알아보고 싶었습니다. 이는 좀 더 간단할 수 있습니다. 실시간 업데이트나 복잡한 통합 지점이 필요하지 않습니다.

저는 SQLite 데이터베이스와 함께 Python, Flask, Bootstrap 등 제가 가장 익숙한 기술 스택을 사용했습니다. "데이터베이스 마이그레이션" 문제에 부딪힐 때까지 모든 것이 순조롭게 진행되었습니다. 이전 장과 유사하게 SQLite가 좋아하지 않는 제약 조건 코드를 생성하고 오류가 발생했습니다.

Exception during DB migration:
 raise ValueError("Constraint must have a name")
ValueError: Constraint must have a name

Claude가 쉽게 해결할 수 있어야 했지만 상황이 점점 악화되기 시작하여 결국 데이터베이스를 처음부터 다시 구축하게 되었습니다. 나는 이것을 플라스크 마이그레이션 디버깅 경험이 부족하다고 비난할 것이지만 Claude는 데이터베이스를 지우고 다시 시작하지 않고는 혼란을 정리할 수 없었습니다.

문제가 해결된 후 관리 패널, 다크/라이트 모드, 검색(SQL 쿼리만 사용) 및 테스트 데이터 생성기와 함께 대부분 기능적인 지식 기반 시스템을 갖추게 되었습니다. 서식과 이미지를 지원하는 오픈 소스 텍스트 편집기인 Quill을 사용하여 제작되었습니다.

“대부분 기능적”이라고 말합니다. 의도적으로 인증이나 다중 테넌시로 복잡하게 만들지 않았기 때문입니다. 기본적인 Flask 경로와 CRUD 작업을 통해 아키텍처를 단순하게 유지했습니다. 아직 API가 없습니다… 아마도 2단계에서 이러한 기능을 다시 살펴보겠습니다.

기능을 추가하면서 Claude가 실제 개발자처럼 한 가지를 고치고 다른 것을 망가뜨리는 것을 계속해서 알아차렸습니다. 그리고 코드 곳곳에 CSS와 Javascript가 흩어져 있었습니다. 때때로 새 기사를 추가하는 것은 가능하지만 편집은 불가능하며 그 반대의 경우도 마찬가지입니다. 가끔 기사 서식 지정 코드가 여기저기 나타나서 Claude에게 정리를 요청해야 했습니다. 그것은 두더지 잡기가되고있었습니다.

프로젝트가 복잡해지면서 마지막 장에서 간략하게 논의한 테스트 자동화가 필요할 정도였습니다. 대부분의 회사에서는 QE를 위한 예산이 거의 없고 대부분의 개발자는 테스트 작성을 싫어하는데 AI가 도움이 될 수 있을까요?

저는 셀레늄과 오이에 대해 상당한 양의 경험을 갖고 있지만 시간이 꽤 흘렀습니다. Playwright는 인기를 얻고 있으며 로케이터 및 재시도에 대한 처리 능력이 더 뛰어나다고 해서 Claude에게 몇 가지 Playwright 테스트를 생성해 달라고 요청했습니다. VS-Code Playwright 확장은 모두 Javascript를 사용하고 있다고 가정하고 Python을 직접 지원하지 않으므로 동물처럼 터미널에서 테스트를 실행해야 합니다.

[즉시]

Playwright와 Python을 사용하여 이 프로젝트에 엔드투엔드 브라우저 테스트를 추가하고 싶습니다. 테스트에서 픽스처를 사용하여 필요한 데이터를 시드한 다음 각 테스트 실행이 끝날 때 데이터를 삭제하고 싶습니다. 테스트는 자체적으로 정리되어야 하며 테스트 데이터를 남겨두어서는 안 됩니다. 테스트를 실행하는 동안 테스트 데이터베이스를 설정하도록 구성할 수 있다면 더욱 좋습니다. 어떤 라이브러리를 설치할지 알려주시고, 제품의 주요 기능을 살펴보고 상위 10개 시나리오에 대한 테스트를 생성하고, 커서 내에서 이러한 테스트를 실행하는 방법을 알려주세요.

[/PROMPT]

첫 번째 시도는 꽤 좋았으며 필요한 라이브러리를 설치하는 방법에 대한 지침을 제공했습니다. 테스트를 위한 파일 구조도 정확해 보였고 뷰포트 크기를 변경하여 응답성에 대한 테스트도 추가했습니다. 좋은 터치입니다... 하지만 생성된 초기 테스트 세트가 마음에 들지 않아 추가 개선을 요청했습니다.

[즉시]

본 상품에는 아직 인증이 구현되지 않았습니다. 해당 기능에 대한 테스트를 생성하지 마십시오. 대신 주제 생성, 편집, 삭제와 같은 관리 기능에 집중하세요. 기사 추가, 편집 및 삭제. 또한 기사 검색 및 보기와 같은 최종 사용자 기능에 중점을 둡니다. 코드를 보고 제품의 상위 10가지 기능을 파악하고 이에 대한 테스트를 작성하세요.

[/PROMPT]

다음 테스트 배치는 조금 나아졌지만 여전히 관리 기능은 없습니다.

[즉시]

대부분의 테스트는 꽤 좋아 보이지만 @admin.html 파일에는 관리 기능에 대한 내용이 전혀 표시되지 않습니다. 주제를 추가, 편집, 삭제하고 기사를 추가, 편집, 삭제하는 테스트가 필요합니다.

[/PROMPT]

이제 제대로 작동하여 다음 앱 시나리오를 테스트하기 위한 코드를 생성한 것 같습니다.

이것은 훌륭한 출발점처럼 보입니다. 이제 Claude의 실행 명령이 올바른지 확인해 보겠습니다. 아쉽게도 그렇지는 않습니다...

[즉시]

귀하의 지시에 따라 테스트를 실행했는데 몇 가지 문제가 발생했습니다.
새 터미널을 열고 "FLASK_ENV=testing 플라스크 실행" 명령과 "pytest 테스트/e2e/" 명령을 실행했습니다. 다음과 같은 문제가 있습니다.

1. 홈페이지에 접속하면 이전에 보던 것과 동일한 데이터가 표시됩니다. 테스트 데이터베이스로 전환되지 않은 것 같습니다.
2. 예외: '/Users/joe/cursor2-kb/tests/e2e/conftest.py' conftest를 로드하는 동안 ImportError가 발생했습니다. 테스트/e2e/conftest.py:12: in from models import Topic, 기사 ModuleNotFoundError: 'models'라는 모듈이 없습니다

[/PROMPT]

Claude는 app.py 파일의 코드를 복제하여 models.py 파일을 생성했는데 그 이유가 무엇인지 궁금했습니다.

이 애플리케이션의 초기 코드는 모델을 포함하여 모두 app.py 파일에서 수행되었습니다. 이것은 잘 작동하지만 다루기 힘든 단일 파일 응용 프로그램이 남을 수 있습니다. 모범 사례에서는 구성에서 모델과 경로를 분리하라고 나와 있는데, 비록 오랜 시간이 걸렸음에도 불구하고 Claude가 나를 데려간 곳은 다음과 같습니다.

[즉시]

제안하신 models.py 파일은 app.py의 코드를 복제한 것처럼 보입니다. 대신 app.py의 모델을 사용하는 것이 더 합리적일까요?

[/PROMPT]

[답변]

실제로는 그 반대입니다. 관심 분리 원칙을 따르려면 모델을 app.py에서 models.py로 옮겨야 합니다. 이는 다음과 같은 Flask 애플리케이션의 일반적인 패턴입니다.
app.py가 애플리케이션 구성 및 초기화를 처리합니다
models.py에는 모든 데이터베이스 모델이 포함되어 있습니다
경로는 별도의 청사진 파일에 있는 경우가 많습니다

[/응답]

그렇습니다. 함께 가요!

그렇게 빠르진 않네요. 자세히 살펴보면…

[즉시]

models.py 파일을 분리하여 어디로 가는지 마음에 들지만 app.py 파일에서 모든 경로를 삭제했습니다. 다른 파일에서는 볼 수 없습니다. 그냥 가버렸네요...

[/PROMPT]

이제 Claude는 app.py 파일에서 모든 경로를 꺼내서 청사진용 별도 파일로 옮겼습니다. 너무 많은 아키텍처 변경이 이루어지고 있어 되돌리고 싶습니다. 모든 것을 다시 작성하려는 뛰어난 새 개발자를 조심하세요! 제안된 변경 사항은 전문 Flask 코드베이스의 모범 사례로 간주되지만 테스트가 완료되어 제대로 작동하는지 확인할 때까지는 이러한 변경 사항을 신뢰하지 않을 것입니다.

[즉시]

블루프린트를 사용하는 것이 전문가 수준의 Flask 코드에 선호되는 방법이라는 것을 알고 있습니다. 그러나 지금은 그러한 리팩터링을 수행하는 것이 불편합니다. 처음에는 엔드투엔드 테스트를 진행하려고 합니다. 그럼 프로젝트 구조를 살펴보겠습니다. app.py 파일 밖으로 경로를 이동하지 마세요.

[/PROMPT]

커서가 되돌리기를 시도했지만 병합 UI가 녹색과 빨간색의 바다여서 변화가 마음에 들지 않았습니다. 새로운 전략: 몇 가지 간단한 극작가 테스트를 마련한 다음 점진적으로 개선해 보겠습니다. 어쩌면 이게 더 나을지도…

어디로 갈지 마음에 들었기 때문에 제안된 테스트 목록을 숨겨 둔 다음 Cursor Composer 창을 닫고 이전 Composer의 모든 콘텐츠를 제거하는 새 Composer를 시작했습니다.

더 간단한 출발점으로 다시 시도해 보겠습니다. 어쨌든 일반적으로 반복 개발이 가장 좋습니다.

[즉시]

Playwright와 Python을 사용하여 이 프로젝트에 엔드투엔드 브라우저 테스트를 추가하고 싶습니다. 어떤 라이브러리를 설치할지 알려주시고, 제품의 주요 기능을 살펴보고 상위 10개 시나리오에 대한 테스트를 생성하고, 커서 내에서 이러한 테스트를 실행하는 방법을 알려주세요.

[/PROMPT]

이번에는 아직 존재하지 않는 기능을 테스트하려는 Claude와 비슷한 문제가 있었습니다. 클로드를 혼낼 시간이에요!

[즉시]

인증 기능에 대한 테스트를 작성하고 계시군요. 로그인 페이지가 있지만 이는 자리 표시자일 뿐이며 실제로 작동하지 않습니다. 누구나 로그인할 수 있는 필드도 없습니다. 프로젝트 코드를 다시 검토하고 Playwright에 대한 상위 10개 테스트 시나리오를 생각해 보세요.

[/PROMPT]

이로 인해 Claude는 사과하고 홈페이지의 검색 기능 전반에 걸쳐 다양한 테스트 시나리오를 만들었습니다. 나는 내가 원하는 테스트를 직접 제공하는 것이 아니라 코드를 보고 기능을 찾기를 원했습니다. 그래도 운이 좋지 않아서 다음과 같이 돌아갔습니다.

[즉시]

보기엔 좋아 보이지만 검색에 너무 집중하고 있습니다. 다음 기능에 대한 테스트가 필요합니다. 검색, 주제 생성, 주제 편집, 주제 삭제, 기사 생성, 기사 편집, 기사 삭제, 기사 보기 및 일부 반응형 테스트를 통해 다양한 화면 해상도에서 모든 것이 제대로 보이는지 확인합니다.

[/PROMPT]

이미 나선형으로 변하기 시작했습니다... 추가 테스트를 위한 기본 프레임워크를 만들었지만 앞으로 존재할 데이터에 대해 너무 많은 가정을 하고 있습니다. 어떤 가정도 하지 마십시오. 이것이 사전 시드된 테스트 데이터베이스를 갖는 것이 가장 좋은 이유이지만 우리는 결국 거기에 도달하려고 노력할 것입니다. 지금은…

[즉시]

이러한 테스트 중 일부는 특정 링크가 유효하고 특정 콘텐츠가 존재한다고 가정합니다. 기사나 주제가 삭제된 경우에는 그렇지 않을 수 있습니다. 필요한 데이터를 생성한 다음 테스트가 완료되면 삭제하여 각 테스트를 자체적으로 포함하도록 만드세요.

[/PROMPT]

이제 Claude는 어쨌든 조명기구 제작으로 돌아왔습니다! 제대로 하고 싶다면 방법이 없을 것 같은데요…

또 다른 문제는 실행 속도를 높이기 위한 일반적인 접근 방식인 병렬 테스트를 실행할 경우 충돌할 수 있는 "테스트 제목" 및 "테스트 기사"와 같은 테스트 문자열을 사용하는 것입니다. 테스트에서 무작위 데이터를 사용하기를 원했기 때문에 다음과 같이 메시지를 표시했습니다.

[즉시]

주제명, 기사명, 기사 내용은 임의의 데이터를 사용해 주세요. 탐색 및 검색 중에 외국어 문자가 제대로 표시되는지 확인하기 위해 외국어 문자에 대한 테스트를 추가하는 것도 좋은 생각입니다.

[/PROMPT]

더 많은 조정이 필요할 것 같지만 이는 매우 합리적인 시작인 것 같습니다. Claude는 다음을 반환했습니다.

변경 사항은 다음과 같습니다.
Faker를 사용하여 여러 언어로 무작위 데이터 생성
다국어 콘텐츠에 대한 특정 테스트 추가
다양한 문자 집합이 올바르게 표시되는지 확인하세요
라틴어가 아닌 문자로 검색 기능 테스트
디스플레이에 문자 인코딩 문제가 없는지 확인
여러 언어로 콘텐츠 제작 테스트
이제 테스트를 통해 애플리케이션이 다음을 올바르게 처리하는지 확인합니다.
일본어(일본어)
중국어(중문)
한국어(한국어)
러시아어(Русский)
그리고 일반 영어 콘텐츠
각 테스트는 자체 임의 데이터를 생성하고 자체적으로 정리하므로 테스트의 신뢰성과 독립성을 더욱 높여줍니다.

생성된 테스트는 다음과 같습니다.

이제 실행해 보겠습니다. 먼저 클로드가 지시한 faker 라이브러리를 설치해야 하는데…

테스트 실행을 위한 다양한 플래그와 옵션이 제공되었습니다. 이전 경험으로 볼 때 이 지침은 모두 올바르게 보이지만 Claude가 만든 pytest.ini 파일을 사용하고 자세한 출력, 스크린샷 및 느린 테스트 실행을 위한 몇 가지 플래그를 전달하여 따라갈 수 있도록 하겠습니다. 시각적으로…

이제 pytest 테스트/e2e/를 실행하여 실제로 테스트를 실행해 보겠습니다.

다음과 같은 오류로 인해 모든 테스트가 실패했습니다.

Exception during DB migration:
 raise ValueError("Constraint must have a name")
ValueError: Constraint must have a name

pytest.ini에서 base_url은 http://localhost:5000으로 설정되어 있는데 제 눈에는 딱 맞는 것 같습니다.

왜 실패했는지 알 수 없어서 클로드에게 물어봤습니다. 그는 몇 가지 작은 수정을 한 다음 pytest.ini 파일을 프로젝트의 ROOT 디렉터리로 옮기고 원래 있던 test/e2e 디렉터리 밖으로 옮기라고 제안했습니다. 나는 이것에 대해 뒤로 밀었고 그는 그것이 어디에 있어도 괜찮다고 말했습니다. 그럼요…

그는 또한 INI 파일과 텍스트 픽스처에 설정된 URL 대신 테스트에서 절대 URL을 사용할 것을 제안했습니다. 잘못된. 나도 그것에 대해 반발했고 그는 동의하고 고쳤습니다. 여기서 믿음을 잃습니다...

이러한 변경 사항으로 테스트를 다시 실행했는데 이제 브라우저가 열리고 지식 베이스의 홈페이지인 기본 URL로 이동하지만 모든 테스트가 여전히 실패합니다. Claude와 함께 몇 차례 더 진행한 결과 루트 페이지 문제가 해결될 수 있을 것 같지만 이제 다음 문제로 인해 실패하고 있습니다.

playwright._impl._errors.Error: Protocol error (Page.navigate): Cannot navigate to invalid URL

로케이터 문제에 더 가까운 것 같습니다.

[즉시]

이제 test_admin.py의 모든 관리 테스트가 다음 오류로 인해 실패합니다: admin_page.fill("#topic-title", data["title"]). 올바른 로케이터가 아닙니다. 수정해주세요.

[/PROMPT]

Claude가 테스트 하나를 수정했지만 다른 테스트는 여전히 로케이터 오류로 인해 실패하고 있습니다. 더 명확하게 표현했습니다:

[즉시]

test_create_topic 외에 @test_admin.py의 나머지 테스트는 로케이터 오류로 인해 실패합니다. 테스트의 모든 로케이터를 검토하고 수정하세요.

[/PROMPT]

Claude가 몇 가지 사항을 변경했는데 이제 또 다른 로케이터 문제가 발생했습니다…

[즉시]

이제 다음과 같은 이유로 모든 테스트가 실패합니다.
테스트/e2e/test_admin.py::test_create_topic[chromium] - AssertionError: 로케이터가 표시되어야 합니다

[/PROMPT]

Claude가 필요한 수정 작업을 수행하는 동안 우리는 한동안 여기에서 여기저기 돌아다닐 것이 분명합니다. 또한 명백하고 불행한 점은 내가 매우 명시적으로 설명하지 않아도 Claude가 애플리케이션과 페이지 요소에 대한 적절한 컨텍스트를 갖고 있지 않다는 것입니다. 단지 클로드에게 “코드를 보고 테스트를 생성하라”고 요청하는 것만으로는 충분하지 않습니다. 기능과 페이지 구조를 잘 알고 있어야 이를 잘 다룰 수 있습니다.

Claude는 pytest.ini 및 conftest.py를 사용하여 테스트 아키텍처를 설정하는 데 도움이 되었지만, 그럼에도 불구하고 즉각적인 테스트 없이 기본 테스트를 실행하려면 몇 가지 조정이 필요했습니다. 실패.

이 프로젝트는 Javascript 확인 ​​및 모달 대화 상자와 함께 프런트 엔드에서 Bootstrap을 사용합니다. Claude는 소스 코드에 여러 모달이 있고 하나만 표시되는 경우(일반적인 디자인 패턴) 이를 처리하는 데 매우 어려움을 겪는 것 같습니다. 여러 번 반복하고 의사 코드로 안내한 끝에 결국 이해하고 테스트에 통과했습니다.

이러한 테스트를 통해 Claude는 로케이터 이름에 대해 많은 가정을 세웠는데, 그 중 대부분은 소스 코드 어디에도 존재하지 않았습니다. 특정 파일을 살펴보라고 명시적으로 지시한 후에야 정리할 수 있었지만 왜 가정을 합니까? 어쩌면 내가 처음부터 올바른 파일을 제공하지 않았을까요? 나는 그 모든 것이 어떻게 작동해야 하는지 아직도 확신하지 못합니다.

전체 프로젝트에 액세스할 수 있는 것처럼 보일 때도 있지만 훨씬 더 명확해야 할 때도 있습니다. 파일에 대한 액세스가 필요한 경우에는 물어봐야 하며 단지 헛소리 코드를 생성해서는 안 됩니다. 왕복할 때마다 API 크레딧이 필요하다는 점을 기억하세요.

많은 테스트 실패 외에도 pytest.ini 파일에 플래그를 전달하는데도 스크린샷이 저장되지 않는 문제도 있습니다. Claude는 나에게 몇 가지 순열을 제안했지만 그 중 어느 것도 문제를 해결하지 못했습니다. Playwright 문서를 살펴봤지만 여전히 해결 방법이 없습니다. 이는 "수정하기 쉬워야 하는" 문제 중 하나처럼 보이지만 수십 개의 Claude 요청을 쉽게 태워도 아무데도 빨리 갈 수 없습니다. 지금은 Claude가 제안한 해결 방법을 사용하여 진행하겠습니다.

Claude를 조정하는 데 너무 많은 시간을 소비한 후 이제 두 개의 테스트만 통과하고 세 번째 테스트는 PASS로 시작하지만 테스트 코드와 픽스처 코드 간의 일부 충돌로 인해 결국 FAIL로 끝납니다. 디버깅하는 것이 점점 지쳐가고 있고 순환적인 대화를 나누고 있는 것 같은 느낌이 듭니다. 나는 제안된 코드 변경 사항을 맹목적으로 병합하고 기적을 바라는 지경에 이르렀습니다.

이 장의 앞부분에서는 데이터와 테스트 코드를 깨끗하게 유지하기 위해 재사용 가능한 고정 장치 및 기능과 함께 테스트 데이터를 시드하고 제거하는 테스트 하네스를 구축하려는 의도였습니다. 그러한 의도는 창 밖이며 이제는 테스트가 통과되기를 원하며 나중에 정리하려고 노력할 것입니다. 익숙한 내용이 있으면 알려주세요...

실행 시 브라우저 창을 최대화하는 것처럼 간단해 보이는 일도 너무 어려운 것으로 판명되었습니다. Claude는 Python과 Javascript로 시도했지만 작동하지 않습니다. 그는 왜 그런지 모르고 Stack Overflow의 천재들이 그 질문에 여러 번 대답했지만 그들의 제안도 효과가 없었습니다. 내 생각엔 파일들 사이에 코드 충돌이 있는 것 같은데, 지금은 그것을 알아낼 만큼 코드를 잘 알지 못합니다. AI가 필요할 때 어디에 있나요!?

생성된 테스트 코드 중 일부에 기대/어설션이 두 개 이상 있는 것을 발견했습니다. 나는 테스트당 단 하나의 주장만 갖는 것이 모범 사례라고 생각하지만, 특히 테스트가 새롭고 아직 신뢰하지 않는 경우 항상 현실적인 경우는 아니라는 것을 알고 있습니다.

나는 올바른 방향으로 나아가는 방법을 찾으려고 노력하는 '신속한 엔지니어'라는 사실을 깨달았습니다. 나는 제품 코드를 직접 작성하지 않았기 때문에 내부 작동 방식에 대해 잘 알지 못했고 Claude가 이를 선택하여 실행할 수 있기를 바랐습니다. 결국 그 사람이 썼는데 기억력이 짧은 것 같아요. 그는 당신에게 갈 수 있을 만큼 충분히 주지만 확실히 한 번 물어보고 돈을 모을 만큼은 충분하지 않습니다.

삶을 더 쉽게 만드는 것은 데이터를 생성하고 삭제하는 CRUD 함수를 호출하는 API를 보유하고 종단 간 테스트는 의도된 기능만 테스트하도록 남겨두는 것입니다. 소프트웨어 애플리케이션에 대한 자동화된 테스트를 작성한 적이 있다면 이 테스트 프로젝트의 단점과 누락된 기능이 너무 친숙하게 들릴 수 있습니다. 실제로 제품 기능을 테스트하기 전에 제품 단점을 해결해야 하는 경우가 많습니다. 제가 API 우선 제품을 만들려고 했으나 곧 통제 불능 상태가 되었던 첫 번째 장을 기억하실 것입니다. API가 없었다면 아마도 직접 SQL 호출이 설정 및 해제에 더 적합했을 것입니다.

다른 프로젝트에서 자동화된 테스트를 수행하고 있고 새 프로젝트의 코드 및 페이지 구조에 익숙하다면 복사/붙여넣기/조정을 사용하면 여기에 설명된 Claude Playwright 접근 방식보다 훨씬 더 빠른 속도를 얻을 수 있습니다. 최소한 코드에 어느 정도 익숙해지고 자신감을 갖고 조정할 수 있습니다. 현재(2024년 11월) 현재 Claude에게 Playwright와의 엔드투엔드 테스트를 생성하도록 요청하는 것은 고통스러운 작업입니다.

---

작가 소개

Joe Giglio는 소프트웨어 업계에서 25년 경력의 베테랑입니다. 그의 경력 중 그는 지역 전화 접속 ISP, 모든 규모의 신생 기업, 잘 확립되고 느리게 움직이는 기업에서 근무했습니다. 매 정거장마다 중요한 교훈을 얻었습니다.

그의 최근 프로젝트는 다음과 같습니다.

원격근무 교육 및 컨설팅: Chiefremoteofficer.com

킨들북 "원격근무, 당신을 위해 일하라"

원격 회사 순위. "원격 기업을 위한 Glassdoor"를 생각해보세요: Remotescorecard.com

Joe의 기본 원칙은 원격 우선, 품질 중심, 고객 옹호, 평생 학습입니다. 그는 내성적이었고 멋있기 전부터 사회적 거리두기를 실천했습니다!

현재 노스캐롤라이나에 거주하고 있는 그는 항상 새로운 기회, 우수한 사람들을 만나고 흥미로운 프로젝트에 대해 배우는 데 관심이 있습니다.

Joe Giglio에 문의하세요: joe -AT- joegiglio.org | 트위터 | 링크드인

위 내용은 커서와 클로드를 사용하여 극작가와 함께 자동화된 테스트를 만드는 부분의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!