chore: Rename unitest to test, simplify Framework configuration

[xerial]

Summary

• Rename sbt project variable from unitest to test (distinguishes from uni)
• Move UniTestFramework from spi package to main package as Framework

Changes

Before:

lazy val unitest = crossProject(...)
testFrameworks += new TestFramework("wvlet.uni.test.spi.UniTestFramework")

After:

lazy val test = crossProject(...)
testFrameworks += new TestFramework("wvlet.uni.test.Framework")

Test plan

• sbt testJVM/test passes (23 tests)
• sbt testJS/test passes (23 tests)
• sbt testNative/test passes (23 tests)

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @xerial, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the uni-test framework's internal structure and configuration. The primary goal is to simplify how the test framework is referenced and integrated within the project by renaming its sbt project variable and streamlining the path to its main Framework class. This change enhances code readability and makes the test setup more intuitive for developers.

Highlights

• Project Variable Renaming: The sbt project variable unitest has been renamed to test for better clarity and to distinguish it from the uni project.
• Test Framework Relocation and Renaming: The UniTestFramework class has been moved from the wvlet.uni.test.spi package to the main wvlet.uni.test package and renamed simply to Framework. This simplifies its import path and configuration.
• Configuration Updates: All references to the old unitest project variable and the wvlet.uni.test.spi.UniTestFramework class have been updated across build.sbt and README.md to reflect the new names and locations.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a nice simplification, renaming the unitest sbt project to test and moving the test framework's entry point class to a more logical location. The changes are applied consistently across the build configuration and documentation. I've added a couple of minor suggestions to further improve code style consistency and update a related code comment. Overall, the changes look good.

[gemini-code-assist]

For consistency with the project name (uni-test) and the framework name (uni-test), it would be clearer to update this comment to refer to uni-test instead of UniTest.

// uni-test - Lightweight testing framework with AirSpec syntax
lazy val test = crossProject(JVMPlatform, JSPlatform, NativePlatform)

[gemini-code-assist]

There's an inconsistent import style. sbt.testing.Framework is used as a fully-qualified name in the class definition, while Fingerprint and Runner from the same sbt.testing package are imported. For better readability and consistency, it's good practice to import all classes used from a package.

I suggest importing sbt.testing.Framework and using its simple name in the class definition.

import sbt.testing.Fingerprint
import sbt.testing.Framework
import sbt.testing.Runner

/**
  * sbt test framework entry point for uni-test
  */
class Framework extends Framework:

[xerial]

Thanks for the suggestion, but importing sbt.testing.Framework would cause a naming conflict since our class is also named Framework. The code class Framework extends Framework: would be a recursive definition error. Using the fully qualified name sbt.testing.Framework is intentional to avoid this conflict.