09-10-2019, 09:36 PM
(09-05-2019, 03:22 AM)xoft Wrote: We have just Tests, we don't distinguish between unit, integration or whatever else. And they are very rare, most of Cuberite was written without any testing. We're adding them as we go along, and I think the 1.13 rewrite is a good opportunity to add many more, so that's what I've been doing so far. The problem is that everything depends on everything else, so testing is difficult.
I think the BlockTypeRegistry tests ( https://github.com/cuberite/cuberite/tre...peRegistry ) are a good example of what I want the tests to look like.
Hey, just FYI/Status, it took me longer than expected (ok, and I binged some show) to get used to cmake and get into the structure of the tests.
Turns out my answer to the question about tests was "missed something", especially the SELF_TEST environment variable. Sure there could be more tests, but I think that's normal. I'm assuming the number of tests is limited due to dev time and there is no issue in me writing more of them.
Some more questions:
I'm uncertain about how strongly you want that intermediate format. Is it fine to directly use the JSON output from the generator? Parsing JSON should have no significant impact on startup performance, it will mostly be I/O-bound anyway, while using it directly should reduce chances of bugs and improve future compatibility.
I don't have an issue writing a converter (actually I basically finished it before realising this), but from my (currently still limited) perspective, I think it should be skipped.
libjsonpp already is in the project, and I'm using that.
Where should I put the build/ci instructions for generating the generator output? And where should the mappings be put, whether JSON or TSV?
Could you give me some hints on where to find a reference to what subset of C11 VC++ supports? I'm on Linux, so I can't just test it, or is CMake configuring gcc to build against it anyway?