Suggestions on how to go about with unit tests

[namithj]

Need ideas on how to go about with unit tests.

1. use wp scaffolding to set it up?
2. will we ship the plugin with tests or do we need a build action

Anything you can think of which can bring a process to this.

[costdev]

1. I think so. This is still a WordPress plugin and the scaffolding has been designed for that context.
2. I don't think we should ship the plugin with tests. A build action is best here IMO. It also means if we add more dev files (phpcs.xml, .editorconfig, etc) in future, we have the system in process to exclude those from a build.

[costdev]

An additional point (relevant, but for later):
Once we've decided on and implemented the infrastructure, before we write any tests, we should decide on the directory/file structure, test class/method naming conventions, and what annotations we use for test methods (e.g. @covers will enable us to generate coverage reports). Having these things decided will make both contributing and reviewing easier.

[namithj]

Tests/test-class.php
Tests/test-class-ajax.php

Is what I follow

[costdev]

A couple of recommendations:

1. Divide into sub-directories based on the "class/module" (Admin Settings, API Rewrite, Utilities, etc).
2. Have a separate test class file for each method.
   • Helps with PHPUnit 11+ compatibility.
   • Avoids large and bloated test files.
   • Makes navigating tests easier.
   • Keeps each file context-specific to the function under test.

For example:

tests/
  AdminSettings/
    AdminSettings_ConstructTest.php -> class AdminSettings_ConstructTest extends WP_UnitTestCase
    AdminSettings_GetSettingTest.php
    AdminSettings_RegisterAdminMenuTest.php
    AdminSettings_RegisterSettingsTest.php
    AdminSettings_ResetAdminNoticeTest.php
    AdminSettings_ResetSettingsTest.php
  ApiRewrite/
    ApiRewrite_ConstructTest.php
    ApiRewrite_PreHttpRequestTest.php
  Utilities/
    Utilities_GetTopLevelDomainTest.php

// And so on.

This helps set us up for the future when things could get bigger and more complex - we just don't know. 😅

FYI: This is very similar to what WordPress Core's test suite restructure was about to start work on. Context Reference

[costdev]

For (2), we can have a GitHub workflow that:

• Checks out the repository.
• Deletes development files and directories.
• Uploads a ZIP artifact.

The ZIP can then be added to a Release entry.

[costdev]

Here's an example for reference.

[namithj]

I am onboard. We will also need a deploy branch in addition to the zip for branch based workflows

[costdev]

Do you think we're ready to begin with an issue?

If so, once the issue is created, I can have a PR up with the scaffolding, composer.json (for dependencies + a test script), .gitignore (to avoid vendor/cache/custom PHPUnit config files), and a sample test for Admin_Settings::get_setting() soon afterwards.

I'm thinking that we can handle the "cleanup" of files via (2) and a deploy branch if needed as a follow-up so it can have its own issue and commit(s) for historical reference.

[namithj]

Yes. Let's begin. Once the basics and one sample test case class is up, let's create issues and open it up for others to come in.