* * * * *
Some thoughts on unit testing from inside an assembler
I've been writing some new 6809 assembly code as well as going back to some
existing projects, trying out the “unit test” feature from my 6809 assembler
[1]. I will admit that running “unit tests” from the assembler is wonderful!
It cuts debugging time since the feedback loop goes from “edit code,
assemble, load into emulator, run, edit code” to “edit code, assemble, edit
code,” which makes it more likely I'll use the feature. Also nice is that
when I'm done with the testing, I change the backend and the testing code is
no longer part of the program. Yes, the tests still reside in the source
code, but they're ignored if not required.
The issue I've always had with “testing über alles” is that it doesn't take
the language or tooling into account, and it's the tooling and language
support that can make or break “unit tests” (whatever a “unit test” is [2]).
Personally, I like it that I can write tests near the code to be tested and
have the assembler run them for me (and it seems like the only modern
language to get this right is Rust). Having “unit tests” in a separate file,
or having to go through several hoops to run the tests is, for me, just too
much friction to use unless forced.
As an aside, I'm amazed that IDE (Integrated Development Environment)s
haven't made writing “unit tests” easier, or just write them entirely as they
already have information about each function—what they take and what they
return. I mean, they already support refactoring, how hard can it be to
support automatic “unit tests?” Or is this a thing I'm missing out on because
I don't use IDEs?
[1]
gopher://gopher.conman.org/0Phlog:2023/12/06.1
[2]
gopher://gopher.conman.org/0Phlog:2022/10/08.1
Email author at
[email protected]
