Write a basic unit test for a custom plugin function

I have this function in my plugin and want a real test suite for it, not just manual
clicking around in wp-admin:

```php
function myplugin_calculate_discount( $price, $percent, $max_discount = null ) {
    $discount = $price * ( $percent / 100 );
    if ( $max_discount !== null && $discount > $max_discount ) {
        $discount = $max_discount;
    }
    return round( $price - $discount, 2 );
}
```

ENVIRONMENT: [plugin has no existing test setup at all, I have PHP 8.1 locally and
Composer available, no CI pipeline yet]

Set this up like a senior dev introducing testing to an untested codebase, in order:
1. Recommend the right tool for this specific function: since it's a pure function
   with no WordPress function calls inside it (no `get_option()`, no `$wpdb`), it
   doesn't need the full `WP_UnitTestCase` / wp-phpunit bootstrap with a real database,
   which is slow and heavyweight. A plain PHPUnit test class with no WordPress
   bootstrap at all is sufficient and much faster to run, and explain when you WOULD
   need the full WordPress test suite (once the function under test calls WordPress
   APIs that need a real or mocked `$wpdb`/options table).
2. Show the Composer setup (`composer require --dev phpunit/phpunit`) and a minimal
   `phpunit.xml`, plus the test class with realistic cases: a normal discount, a
   discount that exceeds `$max_discount` and gets capped, a `0%` discount, and a
   `100%` discount.
3. Add the edge cases a non-expert would skip: a negative price (should this throw, or
   is negative a valid "refund" case that's out of scope for this function?), a percent
   over 100 (does the function need to guard against this or is that the caller's
   responsibility, and should the test document that assumption explicitly rather than
   leaving it silently untested), and a floating-point rounding case (e.g. a price of
   19.99 at 33% needs an exact expected value asserted, since float math can produce
   19.99 * 0.33 = 6.5967 rounding to 6.6, and the test should assert the precise
   rounded output rather than an approximate comparison).
4. Explain how to wire this into a pre-commit or CI check later even without a
   pipeline yet, so the test suite actually gets run consistently rather than existing
   but going stale.
5. Note when to graduate to `WP_UnitTestCase`: if a future version of this function
   starts pulling a site-wide max discount from `get_option()`, the test then needs
   either the full WordPress test bootstrap or a mocking library, and staying with
   plain PHPUnit at that point would mean either skipping that behavior or writing a
   bad manual stub for `get_option()`.

Replace the function and edge cases with your actual code under test.