Add Playwright UI test samples for ChatInput components

[sikutisa]

Add UI test sample that verifies a message can only be sent when the input is not empty in the ChatInput component.

[tae0y]

깃헙 코파일럿 커스텀 instruction

개인적으로 바이브코딩을 할 때, 1) 해당 커뮤니티의 컨벤션을 잘 따르게끔 지시를 하고 싶었고 2) 생성되는 코드들을 충분히 이해하며 반영하고 싶었음. 관련된 커스텀 인스트럭션이 있어 공유.

• xUnit best practice : awesome-copilot/csharp-xunit.prompt.md : xUnit 테스트 구현시 지켜야할 기본규칙, 특히 xUnit 컨벤션 관련된 것들 모음. 해당 레포에 가면 NUnit, MSTest 버전도 있음.
• copilot thought logging : awesome-copilot/copilot-thought-logging.instructions.md : 코파일럿 편집모드에서, 코드 생성을 충분히 이해하며 따라갈 수 있도록 각 단계를 문서로 남김.
• 그외에 '멘토모드'(시니어 개발자로서 용기를 북돋고 생각의 빈틈을 찾아내주는 프롬프트) 등등 다양한 커스텀 인스트럭션들이 있음.

custom chat mode의 경우에는 VSCode Insder 필요: https://code.visualstudio.com/insiders/

우리팀에 맞춘 커스텀 instrunctions

• xUnit best practice : awesome-copilot/csharp-xunit.prompt.md
  • 테스트마다 격리된 환경을 보장하기 위해 xUnit 사용을 권장
  • 테스트명명 : Given_Something_Somehow_When_Do_Something_Then_Something_Happen()
  • 초기화방식 : 웹페이지 로딩 등 비동기 방식이 필요하므로 초기화에 InitializeAsync, 해제에 DisposeAsync 사용
  • Assertion은 Shouldly 사용

현재까지 수정한 버전. -는 기존에 있었던 항목이고,
*는 이번 이슈, PR을 대응하며 수정한 부분.

---
mode: 'agent'
tools: ['changes', 'codebase', 'editFiles', 'problems', 'search']
description: 'Get best practices for XUnit unit testing, including data-driven tests'
---

# XUnit Best Practices

Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.

## Project Setup

- Use a separate test project with naming convention `[ProjectName].Tests`
- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
- Use .NET SDK test commands: `dotnet test` for running tests

## Test Structure

- No test class attributes required (unlike MSTest/NUnit)
- Use fact-based tests with `[Fact]` attribute for simple tests
- Follow the Arrange-Act-Assert (AAA) pattern
* Name tests using the pattern `Given_Something_Somehow_When_Do_Something_Then_Something_Happen`
* Use constructor for setup and `IDisposable.Dispose()` for teardown in synchronous tests
* Use `InitializeAsync` and `DisposeAsync` for asynchronous tests
- Use `IClassFixture<T>` for shared context between tests in a class
- Use `ICollectionFixture<T>` for shared context between multiple test classes

## Standard Tests

- Keep tests focused on a single behavior
- Avoid testing multiple behaviors in one test method
- Use clear assertions that express intent
- Include only the assertions needed to verify the test case
- Make tests independent and idempotent (can run in any order)
- Avoid test interdependencies

## Data-Driven Tests

- Use `[Theory]` combined with data source attributes
- Use `[InlineData]` for inline test data
- Use `[MemberData]` for method-based test data
- Use `[ClassData]` for class-based test data
- Create custom data attributes by implementing `DataAttribute`
- Use meaningful parameter names in data-driven tests

## E2E Tests

* Use Playwright for end-to-end tests
* Use `Page` object to interact with the UI
* Use `ShouldBe` for fluent assertions
* Use specific id or classname for referring to elements (e.g., `UserMessageTextarea`)
* Use `aria-label` for those elements that have no visible text and specific classname
* Split E2E tests into logical groups based on features and happy/unhappy paths

## Mocking and Isolation

- Consider using Moq or NSubstitute alongside XUnit
- Mock dependencies to isolate units under test
- Use interfaces to facilitate mocking
- Consider using a DI container for complex test setups

## Test Organization

- Group tests by feature or component
- Use `[Trait("Category", "CategoryName")]` for categorization
- Use collection fixtures to group tests with shared dependencies
- Consider output helpers (`ITestOutputHelper`) for test diagnostics
- Skip tests conditionally with `Skip = "reason"` in fact/theory attributes

[tae0y]

xUnit의 초기화 방식

• 생성자 : 동기방식, 인스턴스 생성시 실행, Dispose
• InitializeAsync : 비동기가능, 테스트 실행전 실행, DisposeAsync
  • Playwright와 같은 웹페이지 로딩, 데이터베이스 연결, 외부 API 호출, 파일 I/O 작업에 유용함
  • 각 테스트 메서드, inlinedata마다 격리된 환경을 제공함. 각 테스트마다 전/후로 InitializeAsync, DisposeAsync를 호출함

[tae0y]

테스트를 위한 컴포넌트 참조방식

• 프론트 컴포넌트마다 data-testid 추가
  • UI 컴포넌트에 테스트를 위한 속성을 추가
  • 향후 페이지 구조가 변경되더라도 테스트 코드가 깨지지 않음
  • 코파일럿은 이 방식을 가장 권장함
• 프론트 컴포넌트의 ARIA Role을 활용
  • HTML의 의미론적 태그에 암시적으로 부여되는 접근성 속성
  • 이를테면 button은 button이라는 ARIA Role을 가짐
  • 우리 팀은 이 방식을 추천
• 그외 element css selector 등 방식이 있음

왜 ARIA Role 사용이 권장되는지

이 문서에 따르면 Why You Should Avoid data-testid and Use aria-label Instead
aria-label을 사용함으로써 웹을 사람과 기계 모두가 더 잘 읽을 수 있게 된다.

<!-- In HTML -->
<button aria-label="Submit Form">Submit</button>

// In TestCode
await page.getByRole('button', {name: 'Submit Form'}).click();

ARIA Role 종류

주요한 것은 다음과 같고

AriaRole.Button        // 버튼
AriaRole.Textbox       // 입력 필드, textarea
AriaRole.Link          // 링크
AriaRole.Heading       // 제목
AriaRole.List          // 목록
AriaRole.Listitem      // 목록 항목
AriaRole.Dialog        // 모달, 대화상자
AriaRole.Navigation    // 네비게이션
AriaRole.Main          // 메인 콘텐츠

더 자세한 내용은 다음 문서 참조.
MDN WAI-ARIA Role

그래서 aria-label, aria-labelledby 사용할 때는

• button : button 태그에 암시적으로 제공됨. button 이름이 자동으로 aria name으로 참조 가능하나, 아이콘으로 표시되는 버튼은 aria-label, aria-labelledby 속성으로 이름 제공 가능. MDN ARIA: button role
• textarea : type이 text인 input, 혹은 textarea 태그 사용이 권장됨. 해당 태그에 암시적으로 부여되는 속성. MDN ARIA: input role MDN ARIA: textbox role
• 그외에 암시적으로 역할이 지정되지 않거나, 충분하지 않은 경우 aria-label, aria-labelledby를 사용. 둘의 차이는.
  • aria-label : 엘리먼트를 설명하는 텍스트가 눈에 보이지 않는경우. 예시) 이미지 버튼.
  • aria-labelledby : 엘리먼트를 설명하는 텍스트가 눈에 보이는경우. 예시) 이미지 버튼인데 라벨이 있는경우.
  • 참조: MDN aria-label
• 과도하게 남용하지 말자. 추가 설명을 길게 하고 싶은 경우에는 aria-describedby나 aria-description을 사용. aria-label은 DOM에 시각적인 라벨이 없는 경우에 권장된다.

W3C 제공 샘플 코드

https://www.w3.org/WAI/ARIA/apg/example-index/

[tae0y]

향후이슈

• Playwright에서 테스트 실행시 앱을 자동으로 기동하기
  • Microsoft.AspNetCore.Mvc.Testing 패키지 추가
  • 글로벌하게 사전에 앱을 기동, 테스트 마치면 함께 종료
  • 테스트별 격리된 환경을 어떻게 보장할지 검토 필요
• 버튼 클릭 대신 엔터버튼을 눌렀을때 테스트
  • 맥, 윈도우 환경. 한글/영어.

[tae0y]

이슈, PR 연결 꿀팁 (feat. 일구님)
https://docs.github.com/ko/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

resolve, close 등 키워드를 포함해 이슈 번호를 참조하면
PR 닫히면 이슈도 함께 닫힘

[tae0y]

단위테스트와 통합테스트에서의 테스트분리 ??

단위테스트의 경우 실행속도가 빠르며 외부의존성이 적고, 실패원인을 쉽게 파악할 수 있기에 서로 다른 기대값을 가지는 테스트를 한 테스트 메서드에서 수행할 수 있음.

통합테스트의 경우 각 테스트가 하나의 명확한 시나리오만 검증하는 것이 권장됨. 타이밍, 네트워크 등 환경적 요인에 영향을 받기에 테스트를 분리하는 것이 안정성이 향상됨.

[tae0y]

Github Models rate limits
https://docs.github.com/ko/github-models/use-github-models/prototyping-with-ai-models#rate-limits

[tae0y]

한 가지 미진한 사항에 대하여 코멘트를 남김

LLMRequired를 포함하여 테스트를 전체로 돌리면, 채팅 답변을 받아오는 테스트들이 모두 실패함. Button 클릭, Enter 입력 이벤트는 비동기로 wait하지만, 그 이후 LLM에서 답변을 생성하기까지 기다리지 않기 때문임.

await Task.Delay(10000)과 같이 몇초간 임의로 대기하면 테스트는 성공하지만 좋은 방법은 아님.

테스트 Setup에서 NetworkIdle 상태를 보고 앱이 잘 기동되었는지 판단했음. 그러나 우리 앱의 특성상 NetworkIdle로 서버측 요청이 처리 완료되었는지를 알 수는 없음. 현재 우리 앱은 서버측 렌더링으로 처음 기동된 이후로는 Socket 통신을 주고받으며 DOM 상태를 업데이트함. 이때 Playwright의 Load, NetworkIdle, DOMContentLoaded만으로는 서버측 작업이 완료되었는지 판단할 수가 없음.

그래서 렌더링이 시작되기전 로딩 스피너를 UI에 띄우고, 그 다음 서버측 작업이 완료되면 로딩 스피너를 없애는 등으로 명시적인 처리가 필요함.