Testing Termloop

[JoelOtter]

We don't really have any tests other than running the included examples. If anyone has any ideas about the best way to go about this, please say!

[aquilax]

Most of the units are easily testable as they don't directly interact with termbox so IMO it's just a matter of picking the way of tasting (native or any framework) and start writing them. I quite like http://goconvey.co/ for writing tests but mileage may vary :)

[JoelOtter]

@aquilax Thanks, I'll look into that! Wondering what we're going to do for drawing-based methods - perhaps we could run a fake 'game loop' and a fixed-size canvas, and check after a certain number of iterations that given cells are correct.

[aquilax]

If all interaction with termbox is through an Interface then it would be easy to mock that. Also creates some opportunities for other drawing engines 😄

[JoelOtter]

That's a really interesting idea. We currently interact with things based on whether or not they're Drawables, but that still relies on having a Screen. If the screen could be an interface and the concrete version could be, say, TerminalScreen, that would work well. Might be a bit beyond the scope of this project though - I'd like to keep it in the terminal if possible. 😃

[aquilax]

Definitely keep the terminal 👍 but having ncurses adapter is also a possibility.

[JoelOtter]

What would be the advantage of having an ncurses adapter over Termbox? (I've never actually used it.)

[aquilax]

It's widely used and well tested, so someone may prefer it but that does not mean that you have to implement it. The idea is to allow the flexibility for someone to implement it if one wishes to.

[JoelOtter]

Very true.

On 1 Dec 2015, at 12:23, Evgeniy Vasilev notifications@github.com wrote:

It's widely used and well tested, so someone may prefer it but that does not mean that you have to implement it. The idea is to allow the flexibility for someone to implement it if one wishes to.

—
Reply to this email directly or view it on GitHub #22 (comment).