Interest in a runner/watcher?

[Laoujin]

Disclaimer: I realize that this is not something one would merge, or at least not right away. This PR is to test the waters...

I like UnitTesting and Autohotkey and hence also Yunit. It missed some things for me though:

• No clear indication of the reason for a FAIL
• No pretty (colored) output
• No monitoring for changes

So I went ahead and added it...

This is how a first version looks like:

Basically:

• Added runner.ps1 (PowerShell) to run all tests given path+wildcard with option to rerun tests on file changes
• Added YunitPorcelainStdOut for easier parsing by runner.ps1
• Changed Example.ahk to use Yunit.that() instead of Yunit.assert() for Expected/But got
• Added .editorconfig for no source control accidental changes

[mmikeww]

In the past I had my own fork where I had added an expected/actual, as you have done here. I think the function is less readable when you have to separate the params, compared to just passing the equality expression. But I don't see any way around that. I don't like your choice of .that() though for the name. I think i had chosen .assert_equal() but not saying that that is ideal either.

And then in your output you choose the wording "But got".. Seems basic, but I do know that in my fork, I used the wording "actual" and I would get confused as to which exactly was which. Maybe "But actually got:" ?

Just so I understand, the purpose of the 'runner' is to allow you to monitor for changes in the file, and automatically re-run the tests?

I think we'd probably want to keep the Examples as-is, and perhaps just add a new Example file showing how to use your powershell version. Although I have commit access, this isn't my repo, so I'd not want to overwrite any existing stuff if possible.

[mmikeww]

And do you think it'd be possible to modify the existing StdOut module so that it would work with both a normal shell and your powershell requirements? That way we wouldn't need the PorcelainStdOut?

[Laoujin]

Just so I understand, the purpose of the 'runner' is to allow you to monitor for changes in the file, and automatically re-run the tests?

That's right! (implemented with a .NET FileSystemWatcher)

The syntax I borrowed it from was Assert.That(15, Is.EqualTo(result)). But since the "Is.EqualTo" is gone, the That() doesn't make much sense anymore. Perhaps Yunit.Equal() would be short & to the point.

The default StdOut already gives something that is somewhat readable. The PorcelainStdOut just outputs everything with a tab in between. That's why I created a new module, since the Porcelain one isn't ready for human consumption (while StdOut is)

[mmikeww]

I couldn't get the runner to work. Am I doing something wrong? I don't have AHK in my $PATH so I swapped the commented lines:

    # [string]$autohotkeyExe = "Autohotkey" # assumes it's in $env:PATH
    [string]$autohotkeyExe = "C:\Program Files\AutoHotkey\AutoHotkey.exe"

I'm assuming I also had to make sure that the variable name was $autohotkeyExe since your original was just $autohotkey. But when I try it I get 0 failed 0 succeeded

[Laoujin]

Hmm you are correct: When I run the tests in .\doc, it also doesn't find a single test anymore here. I'm at work at the moment so I don't have time to look into it right now but I'll look into it asap.

I've created an issue for me: https://github.com/itenium-be/Yunit/issues/4

Update: Apparently the issue is exactly the Autohotkey exe path (it containing a space doesn't help much). I'm looking into it...

[Laoujin]

Fixed!