Create an interface that will allow to define Unit Tests

[JohnRDOrazio]

The current approach to unit testing isn't quite following the intended usage of PHPUnit. We're extending TestCase and instantiating the resulting class. But according to the intended usage of PHPUnit, TestCase should NOT be instantiated. In order to run tests programmatically, rather than running them directly from an instantiated TestCase, a TestRunner should be used.

https://docs.phpunit.de/en/11.1/extending-phpunit.html#wrapping-the-test-runner

[JohnRDOrazio]

So I've been thinking even more about how to handle Unit Tests. And I'm thinking it would be nice to make it as easy as possible to create a Unit Test, even for someone who knows nothing about coding, but has knowledge of liturgical science. So I'm thinking of creating a UI interface that would allow to create a Unit Test for a specific liturgical event, across a number of given years. The test could be applied to all calendars starting from the Universal Roman Calendar, or it could be filtered for only specific local calendars (for example, a test that only has to do with a liturgical event on the US Calendar, such as the "National Day of Prayer for the Unborn"), or it could be applied to all calendars except specific calendars (let's say there is a festivity that applies to all calendars except a specific national liturgical calendar, because in that regional Roman Missal the festivity has been permanently moved to another date for whatever reason). In this case, representing tests in JSON resources rather than in PHP classes that extend PHPUnit's TestCase could be the best solution. This would make it easy for the UI interface to send a PUT request to create a new unit test, and this would create the JSON representation of the test in the tests folder. As regards assertions, we are only dealing with basically three assertions: 1) assert that a property exists in the given calendar resource for the given year (i.e. the liturgical event is expected to be present in the calendar) 2) assert that a property does not exist in the given calendar resource for the given year (i.e. the liturgical event is expected to not be present in the calendar) 3) in the case that the property exists in the given calendar resource, assert that the timestamp of the liturgical event corresponds with an expected value (i.e. the liturgical event falls on the day we expect it to in the given year)

This basically means re-writing the Unit Tests completely, picking up the structure we started with in the PHP Unit Tests, but transforming them to JSON resources that can be read and dealt with.

Kudos also to @kas-catholic for his input and feedback on the matter!

[JohnRDOrazio]

Started defining a schema for Tests and relative Test files in JSON format in branch new-unittest-interface

[JohnRDOrazio]

New branch has been pulled, this is now a thing!

[JohnRDOrazio]

well at least the basis has been laid, and the tests interface along with the LitCalHealth class are already using the new schema.

Now all we need is an admin backend that will allow to define / create unit tests. This will be done in the LiturgicalCalendar/UnitTestInterface repo, but we will then have to make sure that the LitCal API can handle not only the GET requests, but also PUT or DELETE requests.

[JohnRDOrazio]

As of today, the progress in the UnitTestInterface repo is such that Unit Tests can now be created and existing unit tests can be edited. I'm sure it will get some perfecting over time, but at least there is a working base now, and the LitCalTestsIndex.php endpoint can accept both GET requests (to retrieve a list of defined tests) and PUT requests (to create new tests or update existing tests). I'd say that we're at a point that we can now close this as currently implemented.