No, tests are commonly in the same package as the implementation.

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.

Oh lordy, that log.SetLogLevel() has effects outside the test code.

Setting the log level has effects, but only on an internal wrapper package that neatly zips up the nitty gritty of setting up the logger.

Package-level loggers are an antipattern :(

Certainly it's common to write fewer tests than Python or Ruby projects, where you need tests to verify basic type and existence assertions.

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.

Tests are good! Everything should have tests.

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.

I don't know how many times I've written that kind of test, but I'd bet I can count them in base-10 with just my fingers.

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.