Testing

[ondreian]

Writing scripts is great, testing them is even better.

There are two possible paths here:

1. Mocking
2. Integration

Mocking

test for existance of Lich constant like @sandersch does and do something CI specific if it does not exist. This is definitely the quickest to get running and provides a reasonable balance of power/simplicity.

Integration

Would require a Dockerfile, some /etc/hosts magic, and a faked Game stream.

Testing Data

1. We can write a fully fledged fuzzer (complex, but not impossible), most powerful, allows for property-based testing eventually.
2. We can store some XML and non-XML logs and feed them through, quick, inflexible.

[sandersch]

I mostly write unit tests and structure my code to make it easy to test pretty much everything but interaction with the game. This is usually a pretty natural way to divide things up, so it gets me most of the way to where I want to be.

I started down the path of mocking out the Lich API, and that worked fine for things like Skills/Stats info, but it really felt like I was asserting my implementation more than writing tests likely to catch real issues with stuff like fput / dothistimeout. RSpec et al also don't provide great matchers out of the box as it's not just that you care about which commands are sent, but the order they are sent and timing between them.

I like the idea of integration tests, but it seems like a lot of hoops to jump through to get up and running. I agree that feeding XML logs seems like the least difficult path to implement, but I also agree that would probably be inflexible. It reminds me of VCR which I have mixed feelings about, mainly that is it helpful when refactoring your own code but frustrating to update when an external API changes.

One time I also had a really crazy idea or use a Shattered character or f2p to test against an actual GS instance. Definitely couldn't test everything with that, but could be useful as a smoke test for core scripts like Lich/infomon/etc.