WheelMUD
WheelMUD copied to clipboard
DavidRieman
Build Unit Tests for OutputBuilder
In the new DataFormatter, we have a more efficient output processing that handles prompts and such better too, but at least one bug remains. Output for mixed spaces and color codes is generating extra spaces. We should solve this. However, changing these algorithms can easily cause regressions for other working scenarios. We need to first write a bunch of unit tests for DataFormatter to preserve the cases that are working well, then write a unit test for the problematic case, then solve the problematic case.
The problematic case is exposed by the DefaultPerceivedRoomRenderer's exits output. It is printing like:
[space][space]Routes:[space][space]east (where east is color-coded)
but it should be printing like:
[space][space]Routes:[space]east
Im working on it. Is is possible to make some refactor in DataFormatter for testing without changing logic?
Hi, and welcome! Be sure you working from the latest version coming at https://github.com/DavidRieman/WheelMUD/pull/108, the promptAndOutputImprovements branch - it should be much easier to test than the old version as it doesn't have any fancy inputs anymore and we don't have to solve dependency injection first, IMO. However, if some refactoring ends up being needed to support testing, I am OK with that.
@arty1901, note that @DrunkenImpGameStudio is continuing to make great strides at rewriting and improving our output handling as a whole. DataFormatter itself is actually going away entirely, so unit tests that would have targeted DataFormatter should probably instead get repurposed to target OutputBuilder / OutputParser outputs instead, which are still work in progress. It's unfortunate that 3 of us happened to be active at the same time and happened to pick such similar areas to work on, but I think should be pretty recoverable. I hope that if you had progress yet in defining test scenarios here, that they will be easy to repurpose. If you didn't start it and would like ideas for places to contribute / other code to write tests for, LMK. Unit tests are severely lacking right now so if C# unit tests are an area you have experience with and would like to set some examples for us, it would be a contribution area we'd highly appreciate!
We also now have a Discord linked on the Welcome thread for much closer communications at this granular level of day to day coordination, if you'd like to check it out.
Nearly. While I think you solved the bug (thanks a mil!), it remains that we should do more on the unit tests side: E.G. test cases that cover edge case inputs to the Append(int) method, protect the behavior that we can end a formatted prompt without an extra NewLine, a case with a ton of ASCII formats and verifies the line still wraps at the correct precise place, etc... Renamed ticket title to match new context. @arty1901 if you come back, let us know if you're still interested in this or not; no hard feelings either way. :)
@DavidRieman Im here. I`ll try to finish it at this week. I got your thoughts about test cases and i will try to cover all of these