Add acceptance tests that elaborate expected behaviour

[agatekartik]

While it is nice to have a reference point against which to check the utility's behaviour, it will still be immensely helpful to integrate certain acceptance tests for all features/flags (even the ones that are "todo"). Besides it will also determine scoping vis-a-vis say, the crate, hostname (0.4) that is currently a dependency.

Here's a case in point as far as librarr crate vs utility bin goes:

• when attempting to introduce the "set" option, one way is to invoke the crate hostname(0.4)'s set call, i.e. hostname::set(), and also including the feature "set" in the Cargo.toml
• for a file passed as input with -F, this basically means reading it in a buffer, calling trim() on it and then calling hostname::set() on it - at a very basic level
• however, if one tests it on Linux boxes with a file input, for an input even with a newline say

test name 1
t e s t name

it (hostname::set() ) still sets the name as is i.e. with the new lines and a total of 3 lines of the hostname. This is very different from how the usual Linux/Mac hostname utility behaves - question is, who owns the discrepancy and its fixing - the utility or the crate?

• now, it is unclear whether this will be called out as a bug in the utility or needs to be escalated as a bug in the dependency crate named hostname

Other cases might arise too; therefore, it will be great to articulate all the reqs as test cases

[agatekartik]

No word on this?