Unit testing on an 8-bit CPU
boston.conman.org
boston.conman.org
There's every likelihood that both my original code and the code I write to test it will have bugs, but it's somewhat unlikely that the bugs will be perfectly complementary.
However that will happen too, and so it is not the role of automated testing to eliminate bugs. It is the role of quality control testing to eliminate bugs. The role of automated testing is to reduce the cost of quality control (by reducing regressions and reducing the amount of time required to run manual quality control testing).
I have to credit Sebastian Bergmann with the genesis of this attitude. I took a course on unit testing with him somewhere around 2008 and I said "it seems that test code is just more code, how is it any different from writing code in the rest of your project?" and he said "it isn't, tests are just part of your codebase like all your other code". That was a watershed moment for me -- I always thought I was missing something.
It’s one of the issues companies have when they think they can just replace QA with developers automated tests - it misses every other part of quality except a subset of QC.
I like that perspective. Personally, the difference of "unit" vs "integration" testing from an organization/thinking perspective for me is what has to be available when it runs. We currently have .test.ts and .int.test.ts files in our code base. The former gets to run really fast without any dependencies, and the latter takes longer to run, but has full access to DBs and Redis. That separation just helps split it up for CI.
Thinking about it, you can probably combine them and just require everything is always available, but I've found that the distinction has helped how I think about writing pure functions and allows me to iterate on them with tests easily.
As a side note I really liked using Lettuce when I was working with Django not so much because of the whole “BDD” thing which was lost on me but because of the way they did database fixtures.
I wrote a little automated test runner in PHP that uses the same approach, and later wrote a little test runner in node with the same name (but never implemented database testing in it because I’m not masochistic enough to use asynchronous code to access a database):
That would be the TRS-80 Color Computer. The TRS-80 used a Z80 CPU.
P.S. Lines 9 and 10 in your example test use "==" and "=".
The 6809 team saw themselves as revolutionaries of system software for microcomputers in that the 6809 supported PIC (Position Independent Code) which could be used to implement shared libraries, even in ROM.
So it is totally in character to have your function in one file and have another file with a test harness and another with the actual test that when linked together form a program.
So far as the verbosity of the tests you could solve that with a good macro assembler although I don't remember ever using one for the 6809. The Coco3 could support 512kb of RAM so it could have supported a full phat assembler in OS-9. Macro assembly for the IBM 360 was particularly powerful because you could specify a register in an argument, I am wondering today if you could get away in 6809 with adding an "LD[parameter]" instruction which could assemble to LDA, LDB, LDX or such depending on the value of parameter.
The tests don't have to be as comprehensive as he says they should be, though some fundamental algorithms really can use a comprehensive test.
To generate adequate tests, we would have to simulate part of the actual machine.
Fortunately, he understood we were more likely to write a bad emulator and let us get our exercise instead
it is certainly true that the optimal amount and kind of testing depends on your development environment. if for some reason you find yourself writing 6809 assembly, here are some ways you can make testing cheaper
- don't write the tests in assembly. there are c compilers. forth is also a fine option. or you can test manually from a debugger or monitor program
- forth makes a decent monitor program and macro assembler and is scriptable for testing. it's maybe a lot better at that than it is at being a programming language. there are reportedly very good forths for the 6809
- don't do the development self-hosted. you can simulate a 6809 on a laptop or cellphone hundreds of times faster than real time, and the author is in fact doing that. if you have a big computer with either a 6809 simulator or a debugging umbilical to your 6809, you can run the test scripts on the big computer instead of the 6809, while running the code under test on the 6809, real or emulated. then you don't have to write your tests in c or forth; you can write them in tcl, python, js, lua, squirrel, or whatever you prefer. they can control the 6809 like a marionette, and you can use property testing frameworks like hypothesis, which would be very ambitious to implement on the 6809
- maybe non-time-critical parts of your logic can be written in a language that can be compiled to either the 6809 or the big computer, such as c, so you can test it compiled natively on the big computer. cross-compiled to the 6809, this will generate bloated code that uses more memory, so it depends on how tight you are on space, though the 6809 isn't quite as unfriendly to c as something like a 6502 or pdp-10
- the exception is that if you write the non-time-critical parts in an itc forth instead of c or something, it won't use an unreasonable amount of memory, but it will be a lot slower and more bug prone
disclaimer, I haven't programmed a 6809 since 01985, and then it was in basic, and my forth isn't all that hot either
I assume you’re being hyperbolic here, unless there’s some pre-modern history to the term I’m not aware of?
https://books.google.com/ngrams/graph?content=unit+tests&yea...
I wonder if the etymology of modern unit testing does come from that; but if it did I’d assume the other terms would exist too.
there also seem to be some search hits from 'unit tests' for education, in which the 'unit' is presumably a course or subdivision thereof; https://www.google.com.ar/books/edition/The_Organization_of_... is an example, though sadly google refuses to show me any excerpts, perhaps because i'm in a country they don't like
https://www.google.com.ar/books/edition/Naval_Training_Bulle... does show an excerpt
so i guess the engineering use might date from later, perhaps as late as the 01960s
If you do this as a recreational activity, absolutely feel free do it self-hosted, for an authentic 1980s home computer user experience. To me doing retro computing on modern platforms or using simulated FPGA based hardware defeats the purpose.
my advice 'don't do the development self-hosted' was only intended as a way to reduce the cost of automated testing (and, well, the whole development project) rather than an abstract moral imperative
Is that in the article? I've never heard this before. Unit tests are tests that test a "unit" as opposed to integration tests which test how "units" work together. Of course when it comes to code, what one might call a "unit" is more arbitrary than what one might call a "unit" in an electronics project, which is I think one of the points the author is making.
> Originally, the term “unit” in “unit test” referred not to the system under test but to the test itself. This implies that the test can be executed as one unit and does not rely on other tests running upfront
which is historically incoherent. the author has weakened their post to now say
> Rumors have it that the term “unit” in “unit test” originally referred to test itself, not to a unit of the system under test. (...)
which is still reckless disregard for historical accuracy but now at least it's deniable