refactor: UI Component Refactoring - ChatMessageItem.razor

[qoweh]

Purpose

• close UI Component Refactoring: ChatMessageItem.razor #301

Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type

What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] New feature
[x] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

README updated?

The top-level readme for this repo contains a link to each sample in the repo. If you're adding a new sample did you update the readme?

[ ] Yes
[x] No
[ ] N/A

How to Test

• Get the code

git clone https://github.com/qoweh/open-chat-playground.git
cd open-chat-playground
git checkout feat/301-UIComponentRefactoring-ChatMessageItem-razor

• Test the code

dotnet build

dotnet run --project src/OpenChat.PlaygroundApp 

dotnet test --filter "FullyQualifiedName~OpenChat.PlaygroundApp.Tests.Components.Pages.Chat.ChatMessageItemUITests"   

What to Check

Verify that the following are valid

• ChatMessageItem.razor only contains UI markup.
• all UI logic is moved to ChatMessageItem.razor.cs.

Other Information

입력 메세지(사용자의 userMessage)와 출력 메세지(ai의 assistantMessage)가 있을 때, 각각 비동기 렌더링 된 후의 메세지의 개수 증가, 텍스트 일치(혹은 빈 문자열 X)를 확인했습니다.

Tests (비동기 렌더링 후)

1-2. userMessage의 "개수 1 증가", "텍스트 일치"
3. assistantMessage의 텍스트가 "빈 문자열 아니어야 함" (출력 메세지의 개수 증가와 관련해서는 ChatInputUITests.cs 파일에서 messageCountAfter.ShouldBe(messageCountBefore + expectedMessageCount); 형태로 여러 번 검사하고 있습니다.)
4. assistantMessage의 "아이콘" 확인
5. assistantMessage가 출력되기 전 "spinner"가 보였다가 assistantMessage가 출력되면 사라짐 확인

[sikutisa]

지금 WaitForFunctionAsync를 쓰면서 JS 문자열이 많이 사용되고 있는데, Playwright를 쓰더라도 테스트 작성에 문제는 없는데요.

    [Trait("Category", "IntegrationTest")]
    [Theory]
    [InlineData("Input usermessage")]
    public async Task Given_UserMessage_When_Sent_Then_Rendered_Text_Should_Match_UserMessage(string userMessage)
    {
        // Arrange
        var textArea = Page.GetByRole(AriaRole.Textbox, new() { Name = "User Message Textarea" });
        var userMessages = Page.Locator(".user-message");
        var initialCount = await userMessages.CountAsync();

        // Act
        await textArea.FillAsync(userMessage);
        await textArea.PressAsync("Enter");
        await userMessages.Nth(initialCount).WaitForAsync(new() { State = WaitForSelectorState.Attached });

        // Assert
        var latestUserMessage = userMessages.Nth(initialCount);
        var renderedText = await latestUserMessage.InnerTextAsync();
        renderedText.ShouldBe(userMessage);
    }

예시로 이런 식으로도 할 수 있습니다.
기능적인 부분보다는 어떤 방식이 가독성이 더 낫고, 테스트 코드의 의도를 잘 드러내는지를 기준으로 판단 해보면 좋을 것 같은 데 어떻게 생각하시나요?

[sikutisa]

이 파일은 왜 수정하신 거죠?

[qoweh]

지금 WaitForFunctionAsync를 쓰면서 JS 문자열이 많이 사용되고 있는데, Playwright를 쓰더라도 테스트 작성에 문제는 없는데요.

    [Trait("Category", "IntegrationTest")]
    [Theory]
    [InlineData("Input usermessage")]
    public async Task Given_UserMessage_When_Sent_Then_Rendered_Text_Should_Match_UserMessage(string userMessage)
    {
        // Arrange
        var textArea = Page.GetByRole(AriaRole.Textbox, new() { Name = "User Message Textarea" });
        var userMessages = Page.Locator(".user-message");
        var initialCount = await userMessages.CountAsync();

        // Act
        await textArea.FillAsync(userMessage);
        await textArea.PressAsync("Enter");
        await userMessages.Nth(initialCount).WaitForAsync(new() { State = WaitForSelectorState.Attached });

        // Assert
        var latestUserMessage = userMessages.Nth(initialCount);
        var renderedText = await latestUserMessage.InnerTextAsync();
        renderedText.ShouldBe(userMessage);
    }

예시로 이런 식으로도 할 수 있습니다. 기능적인 부분보다는 어떤 방식이 가독성이 더 낫고, 테스트 코드의 의도를 잘 드러내는지를 기준으로 판단 해보면 좋을 것 같은 데 어떻게 생각하시나요?

넵 이게 더 나은 것 같습니다 그런식으로 수정해보겠습니다!

[sikutisa]

수고하셨습니다!