'net' module: tests and fixes

[natevw]

So far this updates #308 with a very basic test suite, and fixes IPv4 and/or IPv6 address detection.

[natevw]

I'm gonna say this is ready for review alongside https://github.com/tessel/firmware/pull/61— there's still a few missing APIs (#340, #339, #341) and a couple other remaining known issues (e.g. tessel/t1-firmware#60, tessel/t1-firmware#62, #336) but I think the improvements so far here will go a long ways to improving compatibility in many common cases.

(With a little coaxing the various tests can be made to pass even on the device!)

[jiahuang]

should we try to default to "127.0.0.1" if the CC3k can't actually handle it?

[natevw]

This matches node documentation/source and lets the colony test suite pass with the POSIX adapter, as well as preventing a more cryptic error when code proceeds with null host. It's ultimately kinda pointless on the device due to lower-level trouble (tessel/t1-firmware#60), but seems to be the right thing here.

[jiahuang]

Can we add ttt as a dependency? Should be version 1.0.3. Without it the Travis tests fail.

[jiahuang]

Nevermind, the ttt changes got merged into tiny tap

[jiahuang]

Tested and working for basic http server/client examples using this branch along with tessel/t1-firmware#61

This is ready for merge once the Travis tests pass and this gets rebased off of master.

[jiahuang]

How many tests should there be in total? I'm getting 112.
I think you're gonna have to change this to look for the tinytap module in the node_modules folder in order for Travis to pass
require('../../node_modules/tinytap/src/tester.js' || 'tinytap')

I'm also getting intermittent failures on test no 106, but only when I test through npm test. Individually running this test file with tap works just fine. Not sure what's up with that, could be tinytap doing something funky.

[natevw]

Not sure why the relative path is required? That's weird, since I did rebase to master. (And locally is no longer required.)

Here's how many tests I think there are:
cat test/suite/net.js | grep \\bt\\. | grep -v t\\.end says 35
The IP format tests loop…validIPv4.length is 5, validIPv6.length is 14, totalBunk.length is 13 — 32 total and each is iterated over 3 times. So 35, minus the 9 verbatim test calls, plus the 96 actual test calls is 122. Two of those are t.fail calls that should not execute. So 120 is the right number…and perhaps not coincidentally, the number of tests that were running before switching to tinytap.

I will look into the 106 failures next.

[natevw]

Looks like test 106 (under tinytap, that is) is the "port assigned" check on line 109. By "intermittent failures on test no 106" do you mean the assertion itself fails, or do you get a crash like this after test 105?

server-basic

ok 105 ok
Error: Listen on TCP socket failed (-1)
stack traceback:
[T]:src/colony/modules/net.js:480: in function <[T]:src/colony/modules/net.js:491>

That will happen when running the tests while port 1024 are in TIME_WAIT state, which will be for 2*MSL — on BSD-family like OS X this means 1 minute between test runs (4 minutes on Linux). The automatic port assignments are done in JS due to CC3K limitations, and that code assumes it is the only user of the network stack. So if you have other listeners of port 1024ff and/or run the tests back to back, you get that trouble.

[natevw]

(We might be able to avoid that situation with SO_REUSEADDR in the runtime (POSIX) version of tm_net, but I wasn't sure it was worth it and It's Complicated™: http://stackoverflow.com/a/14388707/179583)

[jiahuang]

I get a "not ok" for that test which then stops the other tests from running:

    ok 103 equal
    ok 104 ok
    ok 105 ok
    not ok 106 test/suite/net.js
      ---
        exit:    8
        command: "/Users/jialiya/projects/technical/workspace/test/nate-firmware/firmware/deps/runtime/out/Release/colony net.js"
      ...

    1..106
    # tests 106
    # pass  105
    # fail  1

Weirdly enough I also get 112 tests when running through ttt instead of tinytap.

[natevw]

Looks like probably the same thing, since it's logging an exit status and doesn't keep going up to the "normal" 112 tests. I'll have to look into the 'ttt' thing, unless you've patched ttt it will have trouble regardless. (So maybe that's related? Right now my theory was something to do with event firing or something, but perhaps tinytap doesn't implement t.pass/t.fail right too but masks the problem differently?) Will have to look into tomorrow…

[jiahuang]

ttt got removed since all the changes that it had were merged into tinytap. t.pass/fail calls assert... which could be why its not showing up as tap tests since those only count the console.logs. I count 8 occurrences of t.pass which would make sense if tap isn't counting those.

106 could be the event firing. I only get failures 20% of the time.