feat: add test framework for classifier with dependency injection

[aeft]

What type of PR is this?

feat(classifier): add unit tests

What this PR does / why we need it:
Add Ginkgo test framework for the classifier component with proper dependency injection pattern.

Which issue(s) this PR fixes:

Fixes #45

Release Notes: No

[netlify]

✅ Deploy Preview for vllm-semantic-router ready!

Name	Link
🔨 Latest commit	15a7437
🔍 Latest deploy log	https://app.netlify.com/projects/vllm-semantic-router/deploys/68bb47c85863da0008f8ca61
😎 Deploy Preview	https://deploy-preview-57--vllm-semantic-router.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

👥 vLLM Semantic Team Notification

The following members have been identified for the changed files in this PR and have been automatically assigned:

📁 src

Owners: @rootfs, @Xunzhuo, @wangchen615
Files changed:

• src/semantic-router/pkg/utils/classification/classifier_test.go
• src/semantic-router/pkg/utils/classification/classifier.go

---

This comment was automatically generated based on the OWNER files in the repository.

[rootfs]

@aeft thanks for contributing! can you sign DCO and run pre-commit run --all-files?

Ensure you have a local copy of your branch by [checking out the pull request locally via command line](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally).
In your local branch, run: git rebase HEAD~1 --signoff
Force push your changes to overwrite the branch: git push --force-with-lease origin feature/classifier-test-framework

[rootfs]

can you toggle this test through golang tags? So we can run both mock and real inference in CI.

[aeft]

Do you mean I should add something like

//go:build !integration  
// +build !integration  

so that we can toggle these tests with -tags=integration when we want to run real inference?
If that’s the case, would you prefer the tag name to be integration, or should I use another name that matches our project’s convention?

[rootfs]

yes, something like. You can choose a tag like mock, bert, etc that explains the nature of the tests

[aeft]

Hi. This PR is ready for review. The unit tests have passed, and I also tested it with the real model (using make run-router and curl for the corresponding API).

[aeft]

If this PR looks good, my next plan is to improve the unit tests for the remaining methods in classifier.go.

[rootfs]

@aeft sounds good! when you have additional tests, please use tags so we know which tests are tested in what condition. Thanks

[aeft]

@rootfs Thanks for your review!

I want to confirm whether this aligns with your expectations (since this convention doesn't seem to be established in the project yet, I wanted to check with you. Thanks):

We can add //go:build !integration to mock-based tests (they are unit tests, quick and no dependency) to indicate that they should not run during integration tests (go test -tags=integration ./...). These tests will run when no tags are specified (go test ./...).

For real inference-based tests, we can later add //go:build integration, which means they will require go test -tags=integration ./... to run. If no tag is provided (i.e., running go test -v), these tests won’t run.

[aeft]

@rootfs Would you like to only enable "allow squash merging" in the project settings? This might make the commit history more readable. (Sorry. I assumed the merge would squash commits, so some of my commit messages are a bit vague.)

[rootfs]

go test -tags=integration ./... to run. If no tag is provided (i.e., running go test -v), these tests won’t run.

Yes, that looks good