Closed kevinresol closed 8 years ago
That was a bug in tink_io. Punishment for me trying to be smart. It should work now.
If you spot bugs like this, I would be extremely grateful if you could go the extra mile and push a failing tests (on a separate branch if you wish, but if the lib is broken, then I don't mind the build reflecting that). The coverage of most tink libs is practically zero, so this would help a lot ;)
Sure I can add tests. Haxe's build-in unit test doesn't handle async tasks though. I prefer buddy. Do you have preference?
To be honest, I think all Haxe testing frameworks somehow suck at one point or another, but all of them are good enough to get the job done. As far as async goes, buddy looks like the best solution. Personally, I'm really not very fond of the Should
notation. But please feel free to use whatever you want. While the best code is no code at all, the opposite is true for tests. The more, the better. I will be more than happy to have the problem of our tests becoming too complex :D
I have added some tests. But they are failing.
On nodejs, it is fine. On neko, the following behaviour is observed:
Test Code In Buddy Suite | -lib tink_runloop | Result |
---|---|---|
Yes | No | it can connect but no response |
Yes | Yes | it can't even connect (the worker here doesn't work) |
No | No | it can connect but no response |
No | Yes | success |
I am not sure why the buddy suite even matters...
Buddy and tink_runloop seem to be clashing. That's too bad. I'll see what I can do. Thanks a lot for the tests :)
Maybe @ciscoheat can give us some hints I think I read somewhere that buddy is using threads behind the scene.
I'm happy to help. Maybe you can try to set this.timeoutMs = 0
in the tests. That disables threading, since Neko must create an extra thread to handle async timeouts.
And since you mention a run loop: I'm using promhx for running the tests, it has some special things going on, having an event loop for example. Maybe some conflict there?
(If you want to avoid the should
notation, you can use utest.Assert
instead, it works straight out-of-the-box.)
Where are the tests? Got a branch that I can check out?
@ciscoheat We are talking about the test here https://github.com/haxetink/tink_tcp/blob/master/tests/TestIssue3.hx
Ok thanks, but that's the node test, right? Since Neko doesn't have haxe.Timer.delay
?
Oh i was testing neko. I am using haxe dev, is that the reason timer.delay is there?
Anyway that piece of code is irrelevant, i was just using that to check if the test code is exited early without waiting for a reaponse
On Thu, 12 May, 2016 18:03 Andreas notifications@github.com wrote:
Ok thanks, but that's the node test, right? Since Neko doesn't have haxe.Timer.delay?
— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/haxetink/tink_tcp/issues/3#issuecomment-218713764
Well, there's many things clashing here.
It seems that the presence of buddy makes tink_runloop enter some hanging state. I think that's because both libraries fumble with the main entry point and obviously it doesn't end well for tink_runloop :D
Sorry about that fumbling. :) I've made an example for running the tests manually, but for multi-platform/target tests, that could be a hassle... https://github.com/ciscoheat/buddy#can-i-run-the-tests-manually-without-generating-main
@ciscoheat Thanks for the hint. I've got it to run locally now. Just have to get Travis to like me again.
As for the clash of the libs, I've opened an issue here for those interested: https://github.com/haxetink/tink_runloop/issues/1
Ok, it works now \o/
Thanks a lot for the help guys!
No problem :) Just to be sure, is it working with Travis, even though it's not returning an exit code? The generated main is using Sys.exit
: https://github.com/ciscoheat/buddy/blob/master/src/buddy/internal/GenerateMain.hx#L220 (maybe I should add that to the example)
Oh, good catch! I was happy enough to see 0 failures
but you're right, I need to exit correctly of course.
Ok, seems to work.
The following code works on nodejs. But on neko there is no response.