Re: [dev] Suckless unit testing in C?

From: Rian Hunter <rian+suckless-dev_AT_thelig.ht>
Date: Wed, 25 Feb 2015 11:52:46 -0800

On Wed, Feb 25, 2015 at 07:45:58AM +0100, Anselm R Garbe wrote:
> All you need is creating test input, save the test output and whenever
> you call main() with the same test input, you just check for
> regressions in the test output compared to the expected test output.

Dunno, this seems awfully religious. Not that there is anything wrong with that, I worship a lot of programming gods myself.

Logically though, this advice breaks down for interactive programs with modes of operation that are only accessible after a long sequence of specific user input with output that isn't easily machine-parseable. Unit tests exist for this exact purpose, to give you a way to quickly and easily test these modes. It's much simpler and more robust to call a function and check a linked-list or integer result than to simulate user input and parse the output of ncurses or a framebuffer.

If the subtext of the advice here is to do away with interactive programs, except for the shell, then this philosophy makes sense. Unix started on a teletype device without advanced visual ttys. This advice definitely makes things much more scriptable and that is good. I like git, mpc, xdotool, xsetroot, notify-send, sed, awk, sendmail, etc.

Then again, I like my interactive modal programs too. I like emacs, mutt, irssi, elinks, tmux, st, dwm. These tools are necessary for my daily work. How did the early Unixers get along without these tools? ed, mail, write, I'd guess. Should we go back to that? Personally, I'd rather not.

I'd say that while the Unix philosophy is a very good way to build composable tools for Unix (I would hate if git were an interactive program) but not every user-oriented tool fits exactly fits into that paradigm. When you want an automated way of testing, unit tests can make sense in those cases.

An alternative would be to structure your interactive program as a thin shell whose sole job is to spawn smaller helper commands for functionality and determining what to display. That could work, I guess, but doing that just to follow the Unix philosophy seems a little overly religious. In many cases it would be simpler to have a single program.
Received on Wed Feb 25 2015 - 20:52:46 CET