Wednesday, October 16, 2024
Unit testing from inside an assembler, part V
I've made some major changes to my 6809 assembler, mostly to how the unit testing works. The first change was to assemble the test code elsewhere far in memory from the code being tested (there's a default value that can be changed via an .OPT directive). This separation makes it easier to keep the test code out of the final assembled artifact. The next change was to remove the “unit test feature” as a distinct output type and make it work the rest of the output formats (like the flat binary format, the Color Computer executable format, or the Motorola SREC format). But aside from the internal changes, no changes were required of any existing 6809 assembly code with tests.
And I didn't have to resort to embedding Lua to run the tests.
I consider that a success.
Less successful were the multiple attempts to come up with a table driven format to describe tests that wasted most of the time I spent on this so far. I did devise a format I liked:
.test "atod" .case atod /x := zero /d = 0 , 'zero' .case atod /x := nine /d = 9 , 'nine' .case atod /x := dechalf /d = 3276 , 'half' .case atod /x := decfull /d = 65535 , 'full' .case atod /x := none /d = 0 , 'none' zero ascii "0"z nine ascii "9"z dechalf ascii "3276"z decfull ascii "65535"z none ascii ""z .endtst
which would replace:
.test "atod" ldx #zero jsr atod .assert /d = 0 , 'zero' ldx #nine jsr atod .assert /d = 9 , 'nine' ldx #dechalf jsr atod .assert /d = 3276 , 'half' ldx #decfull jsr atod .assert /d = 65535 , 'full' ldx #none jsr atod .assert /d = 0 , 'none' rts .endtst
Input parameters would be marked by the assignment operator “:=” so it would be “easy” to distinguish pre-initializations with post-checks,
but the word “easy” is carry a lot of weight there.
Any more inputs or outputs would stretch the line out,
and given that I don't support line continuations with a “\” and have a hard line length limit,
never mind the mini-Forth engine that handles the .ASSERT directives doesn't support assignment and is “attached” to the 6809 emulator hitting a particular address and … yeah … I see a lot of work ahead of me if I want to support this format.
More thinking is required.
I think people may be taking the LinkedIn questions not as serious as LinkedIn would like
I'm posting my previous entry to LinkedIn when this time I'm asked “You're one of the few experts invited to answer: Your team is hesitant about new web app technologies. How can you overcome their resistance to change?” And the first response from one of the “experts” that answered is: “Threaten to fire them.”
Wow!
And to think I was scared to answer sarcastically.
Although the “expert” answering is a CTO, so I'm not sure if I should read that as “sarcastic” or “too honest.” I'll assume “sarcastic” until I learn otherwise.
