Change Details

External callers should not need changes, or even be aware, when we replace the RESTBase "lists" endpoints with MediaWiki REST API endpoints. To help ensure this, create a testing plan to ensure compatibility. Ideally, this will include tests that can be run against both the RESTBase endpoints and the new MediaWiki REST API endpoints, to ensure compatibility. This may mean an external testing suite, such as was used for AQS 2.0, is appropriate. But any approach that achieves the goal can be considered. One complication compared to AQS 2.0 is that the Reading Lists functionality includes endpoints that modify data. See the associated [[ https://miro.com/app/board/uXjVMk0jnq8=/?share_link_id=657710521343 | Miro board ]] for endpoint map. See parent task {T336693} for context and details.

External callers should not need changes, or even be aware, when we replace the RESTBase "lists" endpoints with MediaWiki REST API endpoints. To help ensure this, create a testing plan to ensure compatibility. Ideally, this will include tests that can be run against both the RESTBase endpoints and the new MediaWiki REST API endpoints, to ensure compatibility. This may mean an external testing suite, such as was used for AQS 2.0, is appropriate. But any approach that achieves the goal can be considered. One complication compared to AQS 2.0 is that the Reading Lists functionality includes endpoints that modify data. See the associated [[ https://miro.com/app/board/uXjVMk0jnq8=/?share_link_id=657710521343 | Miro board ]] for endpoint map. See parent task {T336693} for context and details. We have three levels of testing planned: # **unit tests**: these are implemented within the extension. These exercise the contract of each individual handler and trait that are part of the new REST API implementation. Because these run on every git (gerrit) push, they are useful for discovering regressions vs expected behavior. But because they do not actively compare behavior to the existing production endpoints, they are susceptible to missing subtle incompatibilities. And because they focus on the internals, they could miss issues with the behavior of the system as a whole. # **mocha tests**: these are implemented within the extension. They exercise the new REST endpoints from an outside-in perspective and test the behavior of the system as a whole. This is very valuable. However, they are less effective than unit tests at exercising the internals of the handlers in detail, and they also do not compare the behavior of the old and new systems. # **compatibility script**: this is an external Python script designed to be executed against both the old and the new endpoints. As such, it is less effective than either the unit tests or the mocha tests at testing internals, and cannot be used to test any additions made in the new REST API. However, it is capable of comparing the behavior of the old and new system, helping ensure callers will not be surprised by any unexpected changes.

External callers should not need changes, or even be aware, when we replace the RESTBase "lists" endpoints with MediaWiki REST API endpoints. To help ensure this, create a testing plan to ensure compatibility. Ideally, this will include tests that can be run against both the RESTBase endpoints and the new MediaWiki REST API endpoints, to ensure compatibility. This may mean an external testing suite, such as was used for AQS 2.0, is appropriate. But any approach that achieves the goal can be considered. One complication compared to AQS 2.0 is that the Reading Lists functionality includes endpoints that modify data. See the associated [[ https://miro.com/app/board/uXjVMk0jnq8=/?share_link_id=657710521343 | Miro board ]] for endpoint map. See parent task {T336693} for context and details. We have three levels of testing planned: # **unit tests**: these are implemented within the extension. These exercise the contract of each individual handler and trait that are part of the new REST API implementation. Because these run on every git (gerrit) push, they are useful for discovering regressions vs expected behavior. But because they do not actively compare behavior to the existing production endpoints, they are susceptible to missing subtle incompatibilities. And because they focus on the internals, they could miss issues with the behavior of the system as a whole. # **mocha tests**: these are implemented within the extension. They exercise the new REST endpoints from an outside-in perspective and test the behavior of the system as a whole. This is very valuable. However, they are less effective than unit tests at exercising the internals of the handlers in detail, and they also do not compare the behavior of the old and new systems. # **compatibility script**: this is an external Python script designed to be executed against both the old and the new endpoints. As such, it is less effective than either the unit tests or the mocha tests at testing internals, and cannot be used to test any additions made in the new REST API. However, it is capable of comparing the behavior of the old and new system, helping ensure callers will not be surprised by any unexpected changes.