test(unit): add comprehensive unit test suites for core library classes & lib

[Shadow243]

New Test Suites

• tests/phpunit/modules/core/mailbox.php – Tests for Hm_Mailbox

  • Bridge pattern for IMAP, JMAP, EWS, SMTP
  • Connection/authentication handling
  • Search across protocols
  • Error handling and edge cases

• tests/phpunit/lib/searchable.php – Tests for Searchable trait

  • getBy() method with parameters and filters
  • Edge cases and errors

• tests/phpunit/lib/scram_authenticator.php – SCRAM authentication

  • Hash algorithm detection/validation
  • Client proof for multiple algorithms
  • Authentication flow

• tests/phpunit/lib/ini_set.php – PHP configuration validation

  • Session security, compression, open_basedir
  • Compatibility: PHP 7.3+, 8.0+, 8.1

[kroky]

Proper bootstrap means we don't call these inside the unit tests themselves. Why would the app path not be defined? Tests should be executed by a single phpunit command which should always properly bootstrap the framework.

[kroky]

This is not the correct place to include such files. Do it in the bootstrap system.

[kroky]

None of the classes or traits called mocks are actual mocks - you copy/implement details from the actual code in the test suite - this is counterproductive as code will diverge over time. See the documentation on how to mock objects https://docs.phpunit.de/en/9.6/test-doubles.html#mock-objects - you add some expectations to methods that should be called and what should be returned but you actually work with the real objects and not some classes that resemble the real classes partially. In theory, it is best to follow this pattern:

• use the object itself whenever possible
• if testing becomes complicated as the original class depends on 3rd party external connections, you can mock the result of some of its methods and return what you want to test
• note that merely testing the return of data that you supplied as a mock is not a productive test. The test objective is to test code that runs in the framework and not code that is written in the tests themselves. So, whenever you want to test a method, see what external connections it uses, mock them and actually call that method on that original class/object and test that it works correctly. There is a subtle but important difference here. The way you did it with these mocks is that you test the mocks themselves which doesn't make sense.

Also, you shouldn't use reflection to set private properties or do similar changes that were not designed to be done with the class in question. If you want to test something that's not available for some reason, do:

• think if it actually needs to be tested. Private methods usually are not tested. Testing the public interface of the class is enough to ensure it works fine as it calls private methods internally, so they become part of the tests.
• if something private really needs to be tested, refactor the original class/interface and make it public or separate it to parts that are testable
  Refactoring original code because of testing is a legitimate use-case, so don't be afraid to do it.

[Shadow243]

@kroky I’ve applied all the requested corrections and fixed the other failing tests.

For Hm_Test_Mailbox, I added some imports in setUp to avoid conflicts. These are only required there and not elsewhere.

[Shadow243]

In addition, in hm-jmap.php I added a few missing compatibility functions (is_supported, get_message_sort_order, and sort_by_fetch) with TODOs and comments. These provide placeholders so we can later implement proper JMAP behavior and confirm everything works correctly with JMAP as well.