DNDBeyond - Needs a "magic number" mapper and a unit test

[trey-kirk-sp]

Several modifiers use a magic number to map them to an ability or attribute. Currently, those magic numbers are defined in various macros. Someday, DNDBeyond is going to shift them by one and the whole framework quietly falls apart. A mapper needs to be used to keep those magic numbers defined in one place to allow us to change them when needed with little churn.

Also, we can make a unit test of sorts. A DNDBeyond character could be created with the restriction is never be modified, once set. It can then be compared against an expected BasicToon object w/ any differences found exposing a regression.

[trey-kirk-sp]

Looks like those magic numbers are defined in https://character-service.dndbeyond.com/character/v3/rule-data?v=3.2.1.

[trey-kirk-sp]

A magic number mapper doesn't look like it will be all that useful. Mostly because so many magic numbers are used in switches which require literal values. So setting that idea aside for now.

However, I know how I want to do unit tests: create a separate library token that has some character JSONs stuffed into macros. Then write the tests in other macros. Results can be tallied by a "suite" macro and reported on there. There should still be at least one test that fetches live data and compares the resulting BasicToon with a know state.

[trey-kirk-sp]

Part 1 of the unittest are in: regression tests. These tests are pulling toon data from a static source (macros) and building BasicToons. Those BasicToons are then compared against another static source (other macros). As new features are added, the static BasicToons will have to be refreshed. Lib:DNDB-TestLibrary#Rebuild Known States should handle that nicely.

TODO: Live sources - These are the ones that will tell us when DNDBeyond changes something. They'll pull from a live character on DNDBeyond and compare their output to a previously known state. These known states will have to be refreshed when new functions are developed, as well.

Token Validation - Need to figure out a way I can test that tokens are getting the right data stuck in the right places.

Wiki - Usage of the tests and how to build the relevant test artifacts needs to be documented.

Better Regression tests - the current regression tests are just all or nothing and have an inherent weakness that can make it easy for a dev to overlook a true failure and encode a regression into the known states. Better unit test should be just that, unit tests: building individual DTOs and making small comparisons. That will likely be an on-going activity.

[trey-kirk-sp]

Addressed the DTO Unit Test requirement by iterating the fields and testing each field. For each field-value difference, the report will show the differences:

        {
            "armorClass": [
                "macro = {\"Dexterity\":3,\"Armor\":10,\"Shield\":0,\"Bonus\":0,\"total\":13}",
                "built = {\"Dexterity\":4,\"Armor\":10,\"Shield\":0,\"Bonus\":1,\"total\":15}"
            ]
        }

We'll also report whenever a field is found in either the test or the control toon, but not in the other.

[mr-ice]

A magic number mapper doesn't look like it will be all that useful. Mostly because so many magic numbers are used in switches which require literal values. So setting that idea aside for now.

Would it work to put that into the build code so that the magic numbers can be inserted as literals at build time?

[trey-kirk-sp]

That's a pretty lofty goal, but has potential. I feel like it's a job that will result in a lot of work and have little payout. My guess is the magic numbers won't ever shift, just be added to as new fields become available. For now the "Live Toon" tests will expose any changes and if we get enough of them (like, once) we can revisit this. But for now I don't think it's worth the effort.

[trey-kirk-sp]

I don't have anything to check the Attack JSON, but with the new DiceRoller that's going to change anyways. So calling it complete.