Adding unit tests to the Hopac solution #155
Conversation
|
@polytypic I've created a scaffold of generative tests, but haven't been able to trigger our bug yet. |
|
Ref #153 |
|
I've removed your webhook @vasily-kirichenko – it was interferring with the PR webhooks. Now the PR is tested on appveyor for Vesa. |
|
@haf that's great. Anyway, I don't think I'm interested in Hopac anymore. |
|
@vasily-kirichenko Yeah... Personally I haven't been working on F# or .NET projects in a long time, a lot of people seem to view Hopac as an undesirable dependency, difficult to learn (which seems to be the case despite there being a book on CML and quite a bit of documentation on Hopac), and would rather see Async optimized.* It would be great if someone would actually optimize Async. |
|
@polytypic Give it a few years; the wind will change. The perplexing thing about building a community is not to care too much about what people think. |
|
The thing left in this PR is to make it compile with dotnetcore; the tests themselves pass. Not sure how to do that right now without spending lots of time getting into .Net Core. |
run
Outdated
| @@ -1,5 +1,6 @@ | |||
| #!/bin/bash -e | |||
|
|
|||
| set -x | |||
There was a problem hiding this comment.
You can pass -x as a parameter to the script like:
./run -x tests
|
Just saying that additional automated tests are a welcome addition. 👍 |
|
@polytypic Is it OK if I turn the repo back to something that is possible to compile? |
|
@haf Does it make sense for me to try fixing this PR so we can use Expecto/FsCheck in Hopac? I'm about to delve into the Job.whileDo stack overflow problem, and I'd be more comfortable modifying Hopac internals with better testing. |
|
Sure, but you can start anew, this PR needs to be rebased otherwise |
This doesn't trigger #153