When a Z* ABAP class is created or changed, perform the following unit test maintenance workflow using the MCP server specified by the user.

On new class creation

1. Check whether the class already has a local test class (CLASS ltcl_... DEFINITION FOR TESTING ... ENDCLASS).
2. If not, create a local test class named ltc_<ShortClassName> in the class test include, where <ShortClassName> is the class name without the leading Z prefix and any common suffix (e.g. ZCL_MM_INVOICE_PROCESSOR → ltc_mm_invoice_processor).
3. Add a setup method and a teardown method to prepare and clean up the test fixture.
4. For each public method in the class, generate two test methods:
   • test_<method_name>_positive — tests the expected happy-path result
   • test_<method_name>_negative — tests a failure, boundary, or invalid-input case
5. Each test method must:
   • Be annotated with FOR TESTING RISK LEVEL HARMLESS DURATION SHORT
   • Follow the arrange → act → assert pattern
   • Call the method under test with representative inputs
   • Assert the expected result using CL_ABAP_UNIT_ASSERT (e.g. assert_equals, assert_not_initial, assert_true, assert_subrc)
   • Include a meaningful msg= parameter in every assertion
6. Design the test suite to achieve at least 90% code coverage of the production class. Cover all branches (IF/ELSEIF/ELSE, CASE, TRY/CATCH) with at least one test each.

On method addition

1. Identify all new public methods in the changed class.
2. For each new method, add two test methods — test_<method_name>_positive and test_<method_name>_negative — to the existing local test class.
3. Implement each test body following arrange → act → assert, covering the happy path and at least one failure or boundary case.
4. Ensure the expanded test suite still targets ≥90% code coverage of the production class.
5. Activate the test include via the MCP server after adding new test methods.

On method change (signature or logic)

1. Identify which methods changed (parameters added, removed, renamed, or logic modified).
2. Update both _positive and _negative test methods to reflect the new signature or expected behavior:
   • If parameters were removed → remove them from both test calls
   • If parameters were added → supply representative values (valid for positive, invalid/boundary for negative)
   • If return type or logic changed → update assertions in both test methods accordingly
3. Re-evaluate whether the updated tests still cover ≥90% of the changed method's branches; add additional cases if not.
4. Activate the test include via the MCP server after the update.

On method deletion

1. Identify which methods were deleted from the source class.
2. Remove the corresponding _positive and _negative test methods from the local test class.
3. If no test methods remain after removal, remove the entire local test class.
4. Activate the test include via the MCP server after removal.

General rules

• Always use the MCP server specified by the user for all read and write operations.
• Never modify the production class logic — only touch the test include.
• Use CL_ABAP_UNIT_ASSERT for all assertions; never use WRITE or MESSAGE in test methods.
• Default annotation for all test methods: RISK LEVEL HARMLESS DURATION SHORT unless the user specifies otherwise.
• Name test class as ltc_<short_class_name> (strip the leading Z and any generic suffix).
• Every public method must have at least one _positive test (valid inputs, expected output) and one _negative test (invalid input, boundary value, or expected exception/error).
• Target ≥90% code coverage across all branches of the production class; cover every IF, ELSEIF, ELSE, CASE, and CATCH block with at least one test.
• After any change, always activate the test include and report success or activation errors.