feat: refactor TextAPI (cf. #50)

Feature

Summary

This MR moves most of the functionality out of tapi.xqm into separate designated modules. As a result, tapi.xqm mainly contains the RESTXQ endpoints.

In detail, the following modules have been created:

• tapi-collection.xqm: creating all information necessary for the TextAPI collection endpoint (/collection.json)
• tapi-manifest.xqm: creating all information necessary for the TextAPI collection endpoint (/manifest.json)
• tapi-item.xqm: creating all information necessary for the TextAPI collection endpoint (/latest/item.json)
• tapi-html.xqm: handling the creation of the HTML presentation of a given page (/content/xxxx.html)
• tapi-txt.xqm: handling the creation of the TXT presentation of a given page (/content/xxxx.txt) which is needed for the collation

All modules have been provided with extensive tests. The module functions and expected parameters aim to be descriptive to such a degree that additional documentation can be kept to a minimum (following Robert Martin's and Martin Fowler's advice).

---

Furthermore, several testsuites are considered and inspected during the unit_test stage of the CI/CD since every module of the ones mentioned above has its own unit testing module.

Compliance to “Definition of Done”

• Unit tests passed
• Code reviewed
• Acceptance criteria met
• Functional tests passed
• Non-Functional requirements met
• Product Owner accepts the User Story

Use Cases

As a developer, having clean and separate modules speeds up my work, and more tests assure my that everything is working fine.

Documentation

• I updated the README (if applicable)
• I provided my functions with appropriate documentation
• I updated existing documentation

Tests

Are we able to test this new feature?

• Yes, everything can be done via unit tests

Changelog

• I added a statement to the CHANGELOG.

Version number

• I bumped the version number in build.properties.

Related Tickets

#50 (closed), #57 (closed)

/cc Mathias Göbel, Frank Schneider, Michelle Weidling

changed milestone to %Ahikar Version 0.11.0

added Ahikar label

added 1 commit

• 2ea5b421 - fix: update trigger API

Compare with previous version

added 1 commit

• 66969d79 - ci: extend test result inspection

Compare with previous version

added 1 commit

• cb27da77 - fix: fix error in path

Compare with previous version

added 1 commit

• 916b77e3 - test: fix dependency between tests

Compare with previous version

changed the description

marked the checklist item Code reviewed as completed

assigned to @mgoebel and unassigned @mrodzis

added 1 commit

• 289d6c17 - test: fix wrong uris

Compare with previous version

mentioned in issue #56 (closed)

added 3 commits

• 289d6c17...87dbff4e - 2 commits from branch develop
• 40af52d5 - Merge branch 'develop' into feature/#50 (closed)-refactor-api

Compare with previous version

You're totally right, thank you!

I like the feedback from the test suite, but it seems unhandy to me. A boolean true or anything more machine readable would be nice.

So what would your preferred output look like?

What is the difference between the testtrigger.xqm and the runner, and (as before) why is the testrigger not part of the tests collection? Now we have three collections where to find related stuff, and I am sure that there are reasons for.

testtrigger is an end point for the test execution by the I while test-runner is for local unit testing. I like to use the latter for a quick check when I work in exide. I also moved test-runner to the tests collection in my latest commit.

@mgoebel I outsourced these questions to #61 (closed) and #62 (closed) since I really need these changes to be merged.

added 1 commit

• ca740ae4 - tests:move runner into test collection

Compare with previous version

changed title from Feature/#50 refactor api to feat: refactor TextAPI (cf. #50)

merged

mentioned in commit 01ed63c2