In which we question a lot of what we’ve written.
Test Every Day
Bless
The Bless potion just combined a few different effects and is pretty trivial (if time-consuming) to test:
696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 |
|
Wizard_Eye
This is a lot more interesting. From the server code, in CreateCharacterEffect
:
831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 |
|
So it creates an NPC clone of the target, puts the same wizard eye effect on the clone, hides the target in shadows indefinitely, brings the clone into the world at the same location as the target, and changes the target to a toad (or rat if they are a thief).
That’s a bunch of stuff to test; let’s try something simple first:
749 750 751 752 753 754 755 756 757 758 759 |
|
396 397 398 399 400 401 402 403 404 405 406 407 408 409 |
|
It works, although I’m starting to get uncomfortable with our lack of parsing on the output: there’s no distinction between the map, the character list, flavor text, and stats bar. False positives are definitely possible where we mistake text in one for text in another.
While we contemplate that, let’s go one step further:
762 763 764 765 766 767 768 769 770 771 772 773 |
|
And something else I’m not comfortable with: the way we handle multiple characters being used in a test. Interesting player interaction is going to take a lot of work; so let’s stop there for now.
Tackle a TODO every other day
Empty Hands
266 267 268 269 |
|
So I add a hook and tag the tests:
40 41 42 |
|
166 167 168 169 170 171 172 173 174 |
|
But then I realized that I already had a hook for clearing all of the player stuff in the database, and it’d be far simpler to just use that after every test than worry about whether I’d altered hands or effects or inventory or whatever.
50 51 52 53 54 |
|
New Player
Rubocop’s been providing me with lots of additional TODOs. It didn’t like my db_insert_player
method, and neither did I:
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
So we move all of the defaults into the DEFAULT_PLAYER
hash:
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
And then we can make db_insert_player
nice and Rubocop-friendly:
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
Fix a Bug in the Legacy Code Every Fifth Day
57 58 59 60 61 62 63 64 65 66 67 68 |
|
I can certainly add a burp to the server code (and I did, briefly); but that’s not where it belongs, is it?
603 604 605 606 607 |
|
…
649 650 651 652 |
|
The drinkDesc
is what’s intended to be shown to the player themselves when an item is drunk. So
let’s fix the test, not the server:
59 60 61 62 63 64 65 66 67 |
|
54 55 56 57 |
|
I use my nifty create_item_from_blank
method, using the existing item as the “blank”, to make a
new item with a changed field.
That works fine, but when I fix the player-in-the-same-cell test:
80 81 82 83 84 85 86 87 88 89 90 91 92 93 |
|
I still don’t see it. Maybe there really is a bug to fix on the server side!
The effect code calls uses SendToAllInSight
, so let’s add a bunch of debug to that:
2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 |
|
After enabling all of the debug, we can see that the bitcount
index into the visCells
array is
behaving oddly.
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -3, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -2, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -1, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell 0, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell 1, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell 2, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell 3, -3(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -3, -2(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -2, -2(bitcount 0)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considers relative cell -2, -2 in bounds.
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell -1, -2(bitcount 1)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considers relative cell -1, -2 in bounds.
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considering relative cell 0, -2(bitcount 2)
12/23/2016 10:09:13 PM: {Unknown} SendToAllInSight from TestAle02_name considers relative cell 0, -2 in bounds.
Another look at the server code, and we see why: bitcount
is only incremented for cells that are
in bounds. Since our test map is quite small, and players are spawning near the edge, a portion of
their immediate area is out of bounds.
I could tweak the server code to behave the way I think it was intended to, but I feel certain that there are probably other edge-of-the-map issues waiting for me. So instead I’ll expand the test map so the players are always safely away from the edge.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering relative cell -1, 0(bitcount 23)
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell -1, 0 in bounds.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell -1, 0 visible?
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell -1, 0 non-null?
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering relative cell 0, 0(bitcount 24)
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 0, 0 in bounds.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 0, 0 visible?
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 0, 0 non-null?
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering TestAle02_name.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering TestAle02_name further.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name sending "TestAle01_name burps loudly." to TestAle02_name.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name sending (filtered) "TestAle01_name burps loudly." to TestAle02_name.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering TestAle01_name.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considering relative cell 1, 0(bitcount 25)
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 1, 0 in bounds.
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 1, 0 visible?
12/24/2016 3:36:38 PM: {Unknown} SendToAllInSight from TestAle01_name considers relative cell 1, 0 non-null?
Much better.
124 scenarios (124 passed)
1241 steps (1241 passed)
50m36.933s