[Playground] Component - button to display a given input #171

[o-ii]

Issue

#171

[Playground] Component - button to display a given input

• UI component that displays a given input when clicking the button
• The input should be passed through a parameter

Description

버튼을 클릭하면 파라미터로 전달된 입력값을 화면에 표시하는 UI 컴포넌트를 구현했습니다.

Summary of Changes

• DebugButtonComponent

  • Debug 버튼을 클릭하면 입력값이 우측 상단의 팝업 알림(Toast)에 출력됩니다.
  • 입력값이 null일 경우, 'Input is null.'라는 메시지가 표시됩니다.

• 테스트 페이지

  • 메인 애플리케이션 흐름과 별개로 UI 테스트를 수행할 수 있는 /tests 페이지를 추가했습니다.
  • 이 페이지는 DebugButtonComponent를 포함하고 있으며, 사용자가 선택한 값이 Debug 버튼 클릭 시 화면에 표시되도록 구성했습니다.

• Playwright 테스트

  • 컴포넌트가 다양한 입력 유형에 대해 올바르게 작동하는지 검증하기 위해 Playwright를 활용한 자동화된 테스트를 추가했습니다.

How to Test

1. 프로젝트를 빌드 및 실행한 후, https://localhost:5001/tests 로 이동합니다.
2. 제공된 입력 옵션 중 하나를 선택합니다.
3. Debug 버튼을 클릭하여 선택한 입력값이 화면에 정확하게 표시되는지 확인합니다.

How to Run Playwright Tests Locally

다음 명령어는 로컬에서 모든 테스트(유닛 테스트 및 통합 테스트)를 한 번에 실행합니다.

# zsh/bash
./scripts/run-tests.sh -c Debug

# PowerShell
./scripts/Run-Tests.ps1 -Configuration Debug

이 스크립트는 애플리케이션을 빌드한 후, 먼저 유닛 테스트를 실행하고, 이어서 통합 테스트(Playwright 테스트 포함)를 실행합니다. 테스트가 모두 완료되면 실행 중인 애플리케이션을 자동으로 종료합니다.

참고: 스크립트를 실행할 때 통합 테스트에서 애플리케이션 포트 충돌로 인한 System.IO.IOException: Failed to bind to address https://127.0.0.1:22000: address already in use. 오류가 발생할 수 있습니다. 이 오류는 간헐적으로 발생하며, 테스트 결과에는 영향을 미치지 않습니다.

Reference

• Fluent UI Blazor
• Playwright for .NET

[github-actions]

Test Results

Tests

📋 Total	✔️ Passed	❌ Failed	⚠️ Skipped

[github-actions]

Test Results

✔️ Tests 35 / 35 - passed in 17.2s
🔍 click here for more details

[github-actions]

Test Results

Tests

📋 Total	✔️ Passed	❌ Failed	⚠️ Skipped
35	35	0	0

[justinyoo]

Playwright 을 로컬에서 테스트하려면 어떻게 하는지에 대한 인스트럭션을 PR 본문에 올려주세요.

그리고 그걸 바탕으로 GitHub Actions workflow 도 업데이트해야 할 거예요.

[justinyoo]

로컬에서 돌려보니 테스트 실패합니다~

[justinyoo]

카운터 페이지 말고 별도의 페이지를 하나 만들어서 거기서 Fluent UI 레이아웃을 적용해 보는 게 좋을 거예요.

[justinyoo]

코드 컨플릭 났습니다.

1. 로컬에서 컨플릭 해결하세요
2. 로컬에서 테스트 돌려보고 푸시하세요

[o-ii]

카운터 페이지 말고 별도의 페이지를 하나 만들어서 거기서 Fluent UI 레이아웃을 적용해 보는 게 좋을 거예요.

별도의 /tests 페이지를 만들어 Playwright E2E 테스트 코드를 작성했습니다.

컴포넌트처럼 Tests 페이지에도 Fluent UI를 적용하려 했으나, Fluent UI의 RadioGroup 컴포넌트가 다양한 타입(double, DateTime 등)을 지원하지 않아서, 다양한 inputType(int, double, string)을 테스트하기 위해 Tests 페이지에는 Fluent UI를 사용하지 않았습니다.

[o-ii]

Playwright 을 로컬에서 테스트하려면 어떻게 하는지에 대한 인스트럭션을 PR 본문에 올려주세요.

그리고 그걸 바탕으로 GitHub Actions workflow 도 업데이트해야 할 거예요.

Playwright 테스트를 로컬에서 실행하는 방법에 대한 인스트럭션을 PR 본문에 추가했습니다.

1. 첫 번째 커밋Add DebugButton component to display input parameter에서는 로컬과 GitHub Actions 워크플로우에서 오류 없이 실행되는 Playwright (E2E) 테스트를 작성했습니다.

2. 두 번째 커밋Add unit tests with bUnit for DebugButton component에서는 bUnit을 사용하여 dotnet run 없이 컴포넌트만 테스트하는 유닛 테스트 코드를 추가했습니다. 현재 단계에서는 Playwright E2E 테스트보다는 bUnit을 사용한 유닛 테스트가 더 적절하다고 생각하는데, 프론트엔드 관련 코드를 모두 Playwright의 E2E 테스트로 통일하는 것이 좋을까요?

3. 예시로 제공해주신 테스트 코드에서 [Property("Category", "Integration")]를 사용하셨는데, Playwright로 작성한 코드는 모두 Integration 카테고리로 통일하면 될까요? UI 테스트에서 유닛 테스트는 "Unit", 통합 테스트와 E2E 테스트는 "Integration"으로 분류하면 될까요? 어떤 기준으로 카테고리를 작성해야 할지 궁금합니다.

[justinyoo]

현재 브랜치의 코드베이스가 머지 컨플릭 처리하면서 꼬여있습니다. 최신 코드베이스로 새로 브랜치 딴 후에 본인의 변경사항만 보이게끔 수정해 보세요.

[justinyoo]

2. 두 번째 커밋Add unit tests with bUnit for DebugButton component에서는 bUnit을 사용하여 dotnet run 없이 컴포넌트만 테스트하는 유닛 테스트 코드를 추가했습니다. 현재 단계에서는 Playwright E2E 테스트보다는 bUnit을 사용한 유닛 테스트가 더 적절하다고 생각하는데, 프론트엔드 관련 코드를 모두 Playwright의 E2E 테스트로 통일하는 것이 좋을까요?

bUnit은 사용하지 않도록 하겠습니다. bUnit을 쓰게 되면 테스트 프로젝트가 플레이그라운드 프로젝트에 의존성이 생기는데 현재 이 부분에 문제가 있어서요.

3. 예시로 제공해주신 테스트 코드에서 [Property("Category", "Integration")]를 사용하셨는데, Playwright로 작성한 코드는 모두 Integration 카테고리로 통일하면 될까요? UI 테스트에서 유닛 테스트는 "Unit", 통합 테스트와 E2E 테스트는 "Integration"으로 분류하면 될까요? 어떤 기준으로 카테고리를 작성해야 할지 궁금합니다.

플레이그라운드 테스트 코드에만 [Property("Category", "Integration")] 데코레이터를 사용합니다.

[o-ii]

bUnit은 사용하지 않도록 하겠습니다. bUnit을 쓰게 되면 테스트 프로젝트가 플레이그라운드 프로젝트에 의존성이 생기는데 현재 이 부분에 문제가 있어서요.

bUnit 테스트를 삭제하고, Playwright 테스트만 유지한 상태로 다시 커밋했습니다.

플레이그라운드 테스트 코드에만 [Property("Category", "Integration")] 데코레이터를 사용합니다.

Playwright 테스트용 /tests 페이지를 생성하고, 비어 있는 페이지에 테스트용 컴포넌트를 추가했습니다. 앞으로 다른 플레이그라운드 테스트 코드를 작성할 때, /tests 페이지에서 각 테스트에 개별적으로 접근할 수 있는 메뉴를 추가하는 것이 좋을까요? 아니면 모든 테스트 컴포넌트를 한 페이지에 배치하는 방식이 더 효율적일까요?

[justinyoo]

Playwright 테스트용 /tests 페이지를 생성하고, 비어 있는 페이지에 테스트용 컴포넌트를 추가했습니다. 앞으로 다른 플레이그라운드 테스트 코드를 작성할 때, /tests 페이지에서 각 테스트에 개별적으로 접근할 수 있는 메뉴를 추가하는 것이 좋을까요? 아니면 모든 테스트 컴포넌트를 한 페이지에 배치하는 방식이 더 효율적일까요?

현재 상태로 냅두셔도 됩니다. 이건 다른 사람들이 추가하는 컴포넌트 값을 확인하기 위한 테스트용 버튼이고 이 버튼 말고 자기들이 추가하는 컴포넌트와 버튼과 연결시켜서 해당 컴포넌트가 제대로 작동하는지 확인하는 용도기 때문에 궁극적으로는 없어질 컴포넌트입니다.

[justinyoo]

코멘트 남겼습니다.

[o-ii]

코드에 대한 설명을 코멘트에 남겼습니다. 수정하거나 보완할 부분이 있는지 검토 부탁드립니다.

[justinyoo]

Fluent UI 컴포넌트로 바꿔보세요.

[justinyoo]

코멘트 남겨뒀습니다!

[justinyoo]

고생하셨습니다! LGTM!