Write tests

[joukos]

Now that there's more than enough features, should also add proper tests.

[gdkrmr]

How do you test something like this, except trying it out on hardware?

[joukos]

Some hardware related things are of course impossible to test in pure software, but since the hardware is controlled simply by spitting bytes at it, we could for example:

1. write some code that does something with the hardware, such as initialize a particular display or draw a frame to it
2. verify that this code actually does the correct thing with the hardware
3. change the hardware driver used in the test to a mock: instead of outputting the command and data bytes to the display, save them somewhere
   • the SPI related methods should be modified to handle such a simulation, for example wait_until_idle should just return instead of trying to read an unconnected pin, etc.
4. make a test that simply verifies that when it's run, the data that gets sent is the same that was verified to work earlier

Implementing it nicely needs a bit of effort, but even the most simplistic regression tests like these would catch bugs and help a lot when for example optimizing the code, because it's easy to verify that the optimized code produces the exact same output as it did before. And if it doesn't, it may also be fine, but then we can test it with the actual hardware and update the test if the new way works.

There's also a (very crude, for now) Bitmap driver that can be used to visually verify what should be drawn on screen, check the orientation etc., but all these would need more attention to be useful.

Also, all the non-hardware related parts should have no particular problem with testing them. It's boring, sure, but should be done regardless.

[waynew]

☝️

Basically you decide on a testing philosophy. Testing is all about trade-offs. You can test things narrowly or broadly, but at some point you have boundaries beyond which you simply say, "We're going to pretend everything out here does the right thing" (Or even the wrong thing for certain cases).

For papertty that's basically "assume that the pi is behaving certain ways". Since, from papertty's perspective, that's about as reasonable an expectation as you can make. Sure you could like... setup a webcam and an e-ink display, but that's probably overkill for this type of project 😂

Instead, we can try different scenarios:

• you don't have access to the GPIO/SPI pins (including them just being disabled)
• you have access but they're busy
• you have access and they can do the right thing
• ???

Basically you write some testing tools/mocks that accept/return in similar ways to an actual device, and then have that produce expected behaviors. Granted, you do have to write that and verify it against actual observed behaviors, but the benefits can be pretty huge. Like not requiring access to dozens of e-ink displays.