Low-level unit tests [WIP]

[pscollins]

Without unit tests, it's very difficult for anyone else to contribute: we have no way of knowing if our change just broke core functionality. Even a hacked together shell script that spins up a local instance and checks for the right return codes in response to various ssh commands would be better than nothing.

If you point me towards your favorite unit testing framework I can try to get started on some --- I'm not very familiar with the node.js ecosystem but I could probably stumble my way through eventually.

[hmngwy]

Currently working on this. My mistake is that registration uses a curses-like UI. Other than causing term issues with some users, I'm not sure how I'd test that.

[pscollins]

That sort of stuff is pretty much beyond testing, imo, but some tests for the file parsing logic (.txt and .md) would make it easy to put together a pull request that implements https://github.com/hmngwy/weblog.sh/issues/17 without worrying that I've brought the whole system down. UI bugs across many terminals are probably close to impossible to catch with unit tests, but stuff like:

• Given an input file, ensure that it produces the right HTML
• Given a .txt and .md file describing the same content, ensure they produce the same HTML
• Given a command string (i.e. key "A_BOGUS_KEY"), ensure that it is recognized as a command
• Given a key command, ensure that it sets the public key associated with a dummy user in a mock mongodb
• Push a file, make sure it shows up from ls, rm it, make sure it doesn't show up in ls anymore
• etc

I'm not sure how easy it is to stub out stuff like the stream objects, but I assume that whatever library you're using provides functionality to do it.

[hmngwy]

@pscollins ok, registration UI out of the way see #10.

This is definitely what I'll be working on next. I'm new to TDD so it may take some doing (I at least know that making tests now once the code is already written is poor practice).

If you want to give it a shot, just send a PR, I don't have any framework preference, I might even just use nodejs assert. My only preference is that it be simple/small if possible.

[pscollins]

Sure --- I'll do some refactoring along the way to make it easier. As I said, I don't know much about node, so be ready to tell me off if I write code that's strange.

[hmngwy]

Moving forward let's talk about the low-level tests here and just reference outward instead of in.

[hmngwy]

Let's keep the var self = module.exports library definition as in ffcfd56, and do the same with future refactoring, instead of changing how we reference them in exec.js and etc., that way usage is more flexible between tests and actual code - and will encourage making the functions atomic.