That's an internal test, meaning it has access to the package internals. A better test would test from outside the boundaries of the package to only interact with exposed symbols.
This is starting to change, perhaps not in Ruby but JS and Python now have commonly-used pre-compile typecheckers with typesystems fancier than your typical typed C-descendant language, annotation stubs for the standard or popular libraries, etc. I wouldn't be surprised that if in a couple of years, the default for a new Javascript project would be more typechecked than Go, strange as it is to say.
Sure! I think that's especially true of Javascript.
I would just caution people against doing direct comparisons of unit test suites between Ruby/Python and Go projects, because a lot of Ruby/Python testing really just mitigates deficiencies in those languages, and those deficiencies have created a sort of culture of exuberant, creative testing that isn't present in other languages.
I know only of Flow for JS, but are there signs that it's commonly used, or are there other JS typecheckers with a more optimistic trajectory?
It looks to me more like compile-to-JS languages are winning this race. Which is good, as it enables sthings like ClojureScript and Elm. Also many of us think the lack of static types is the least of the problems in JS.
Flow and TypeScript are used a fair bit and both have adoption in big organizations that make big, commonly used tools. I don't think any of the compile-to-JS languages have ever really got quite that far and I'm somewhat skeptical they will.
Ah. I guess due to the superset-of-JS property you might kinda sorta see it as annotated JS, though it has its own syntax and has to go through a compiler to produce runnable JS.
edit: Seems the TS tools also have JS linting functionality, where you put JSDoc annotations in comments and use the new --checkJs options, I guess you may have meant this too.
Some parts have unit tests. In addition, the "stresser" component, runs a resolve on the top million domain names, and we run this on every push on our development fork. This provides a real workout. We certainly need to produce a library of example wire data and expected responses. This would be a great contribution that we'd love to incorporate.
I did find this one: https://github.com/tenta-browser/tenta-dns/blob/master/src/t...
That's an internal test, meaning it has access to the package internals. A better test would test from outside the boundaries of the package to only interact with exposed symbols.