Lack of tests

[jameshalsall]

I really like this module, but I don't feel 100% confident when updating it because of the lack of tests.

Ideally we want tests for:

• request encoding
• request decoding
• client (against a mock IPP server)

We could do this gradually over time, maybe starting with the request encoding/decoding as a priority.

If you've done any work on testing outside of this module, or have a collection of example payloads we can use as fixtures, I'm happy to make a start.

[phin1x]

tests for request encoding and decoding is on my to-do list for a long time. but I won't write tests for clients against a mock ipp server. the ipp server implementation differs from vendor to vendor.

[jameshalsall]

Any implementation of a mock server would prove the communication works between client and server though. I don't think we need to prove that this works with all IPP server implementations as that's not the goal.

[phin1x]

with this kind of tests you just prove that the http client library from the go std lib works. the only thing of the client which should be tested is the url generation. the other things are already covered by the ipp encoding and decoding tests.

[g41797]

just brainstorming

run automatically docker compose with cups or ippsample
so tests will work with real (almost) print server
suitable for e2e test
but using TestMain (i hope) it also may be feasible for regular unit tests

btw - i think e2e tests are more important for this kind of s/w

[phin1x]

I agree that E2E is necessary, but it's not easy. First of all, there is no reference server implementation. Cups could be used, but Cups has extended the IPP standard with many of its own features, and every print server I've worked with has had its own quirks.

Since I don't have time to implement E2E testing, I'm marking this issue as “help wanted.” If anyone would like to contribute, I would appreciate it.