Make test_init and test_dracor_info less strict

[cmil]

The tests test_init and test_dracor_info are too specific and will fail as soon as a minor upgrade is made to the DraCor API.

pydracor/pydracor/test_dracor.py

Lines 20 to 24 in 537d7c5

	def test_init(self):
	self.assertEqual(self.dracor.name, "DraCor API v1")
	self.assertEqual(self.dracor.status, "beta")
	self.assertEqual(self.dracor.existdb, "6.2.0")
	self.assertEqual(self.dracor.version, "1.0.0")

pydracor/pydracor/test_dracor.py

Lines 58 to 64 in 537d7c5

	def test_dracor_info(self):
	self.assertEqual(self.dracor.dracor_info(),{
	'name': 'DraCor API v1',
	'version': '1.0.0',
	'status': 'beta',
	'existdb': '6.2.0',
	'base': 'https://dracor.org/api/v1'})

I suggest the following adjustments:

• only assert that that the major number of version is 1, the tests should succeed for any 1.x.x version
• allow the following values for status: "stable", "beta", "alpha" or ignore this property altogether since it should not really matter to pydracor (it will change to "stable" with the next production update, we forgot to change it for the 1.0 release)
• do not make any assertions about the existdb version, it can change in no predictable ways and should be irrelevant for pydracor
• allow for other properties of the info object to occur (hint: the next API update will add the URL to the OpenAPI documentation)

[hsluytergaethje]

Since the new testing method works with TestDraCor, this issue should be obsolete. Can you confirm that @cmil?

[cmil]

pydracor/test/test_api_wrapper.py

Line 19 in de28a6b

self.assertEqual(info.existdb, "6.4.0")

still tests a specific eXist DB version, for example. Since you are pinning the API version by ways of the compose.dracor_api.dev.yml this should at least not break without you changing anything. But you may potentially have to adjust the tests with each upgrade of the API, which is not an ideal test design.

Ideally you want to test the inner workings of pydracor and make sure it works with all kinds of data. Looking at the tests again, I would say almost none of them does this. What they do is testing the API and that it delivers a specific version of the (TestDraCor) data. That's not primarily what these tests should do. They should make sure that the pydracor logic works with all kinds of imaginable, API compliant inputs.

That said, these test are not useless, because they help us find bugs in the API, although that should actually happen in the dracor-api schemathesis tests. So I would keep the tests for know, but keep in mind to redesign them to actually test business logic instead of data. Maybe for that purpose, a dedicated pydracor test repo, where you control the test cases would also be more suitable than TestDraCor which hasn't been designed with unit tests in mind.