Closed LinguList closed 4 months ago
Since we don't have complex sounds to be tested
What would you consider a complex sound?
Otherwise, I don't see a problem doing the tests with linse
instead of pyclts
.
Sounds that are super generated and not in the 8000 that CLTS accepts, or alias cases, like "th" which is also nto resolved well by linse.clts.
Hm, I am not sure - as stated earlier in the PR discussion, I think the most common use case would be using CLTS, so I think it would be useful testing with that system as well. What would be the benefits of testing with linse
instead of pyclts
?
Tests on github run automatically if you set this up properly. To run automatically, you must make sure all can be installed without user intervention and data loading. This is not the case of clts.
But it is the case for linse, which also has 100% test coverage and is maintained and keeps the most recent version of CLTS, but with a lookup of all generated sounds rather than actively generated sounds.
Ahh, I see! Sure, then it makes a lot of sense - I'll adjust the tests accordingly :)
The only issue would then be, that we can not test whether Sound
objects (generated by CLTS) can be processed correctly... (a function that we currently support, and I think would be reasonable maintaining)
Linse is on pypi and offers a command to convert a sound to its clts name. Since we don't have complex sounds to be tested, so we make sure we can put this easily up with tests, etc. on pypi and integrated tests in github.