Tests refactoring

[oleggromov]

A bunch of changes:

• trying to remove as much repetition as possible (particularly in test initialization) by moving initialization into beforeEach blocks
• grouping tests in logical groups
• removing test environment (test file existence) tests — there's no need to test environment together with the code
• replaces stream with a buffer in a test case name

Questions

Seems like reading-writing test files in every test case is rather useless and, even worse, makes tests code too complicated. Ideally, each test case should consist only of one check, but I don't know yet how to achieve such simplicity. Maybe you have any thoughts?

I also wonder why are the file parameters such as cwd and base needed. Once I remove them nothing happens, but I don't sure if this is a regression-safe change.

[lazd]

So the cwd and base arguments are part of the Vinyl API. They do have sensible defaults, and since we're not using those values in our assertions, it's probably fine to remove them.

[lazd]

We could probably abstract reading the test files into a function that just matches the file contents against a path, something like fileMatches(file, 'path'), but we'll have to read in the expected output at some point.

We're not actually writing output, just getting the Vinyl file object from the stream, so that's fine.

[oleggromov]

Hi Larry, thanks for feedback!
I recently removed unnecessary options and tried to simplify each test case even more by moving check function outwards to the beforeEach block. Although there are a lot of other ways to brush tests' code and even make checks more precise, maybe we can leave this improvement as is by now?

In fact I hadn't had a plan to refactor tests, but started writing code that consistently solves #65 problem and found that I need to improve tests readability in order to complete my PR with written tests for the new code.

[lazd]

Yeah, this is good. We could spend all day making tests look simpler, but this is a great improvement as-is.

Can you do me a favor and double check that there are no false positives as a result of this refactor? Simply invert every expect and make sure they all fail. Sometimes the asynchronous nature of a test gets overlooked in these kinds of refactors, and it ends up passing with flying colors when it ought to fail. If it passes that little audit, then we're good to merge.

[oleggromov]

It's all arranged!
I'll perform additional check on each test to be certain of it correctness and write to you once all checks finish.

[oleggromov]

Hi Larry. I've just checked if every test fails with inverted assertion and this is true. I've also become convinced of the test verifying finish triggering also fails once the event is renamed.

[oleggromov]

@lazd What do you think about this PR? I need it to complete #67 too.

[lazd]

Let's merge it!