Problem: I've been worried about merging these version bump pull
requests since we don't have many tests, and I *really* don't want to
merge any catostrophic breaking changes anywhere.
Solution: Add some tests that are more comprehensive, starting by
creating a temporary SSB database and keypair and then editing the
profile, previewing a message, publishing a message, etc., until we have
a handful of small functions actually being tested. This won't ensure
that everything works forever, and it *really* doesn't test replication,
but it should help increase our confidence that test success means that
fewer things are broken.
Problem: There's an intermittent test failure on Travis CI that seems on
only happen when we have two test suites. Since the lifecycle suite only
tests a subset of the basic test, we can safely remove it without
compromising any test coverage.
Solution: Remove the redundant lifecycle test and try not to think about
the problem too much. Maybe in the future when we need a second test
suite we can resolve this problem, or maybe the underlying bug will be
resolved downstream (e.g. https://github.com/tapjs/node-tap/pull/662),
but right now I think the benefits of "no intermittent test failures"
outweights the costs of "all tests must go in one file".
Problem: The Windows tests seem to be failing, it looks like a timeout
problem? Also there are a handful of debug statements around the code
that can be safely removed.
Solution: Double the timeout length and remove debug statements.
Problem: The test suite isn't closing the database because `app.close()`
only affects the HTTP server. This means that tests don't exit cleanly
and sockets remain open and all sorts of really fun stuff that we don't
want while writing tests.
Solution: Refactor `src/ssb.js` so that we can exit cleanly and have
less rope to hang ourselves with. Add a small lifecycle test that can
help us ensure that the bare minimum lifecycle events are working
correctly, plus now the previous tests are passing on my machine too.
Problem: ESLint and TypeScript help catch some types of regressions, but
they don't protect us against obvious stuff like "the server won't
start". This means that humans need to test a bunch of stuff manually,
and that can be really tedious and exhausting.
Solution: Yesterday someone invented this cool concept called "testing"
where you write automated tests for your software to ensure it actually
works the way you expect. It might have beeen invented before yesterday,
I don't know. Anyway, this solution adds a bunch of tests that send HTTP
GET requests to a bunch of endpoints to make sure the server is at least
returning HTTP 200 responses. It also fixes a race condition where HTTP
server was available before the readme / version strings were loaded.
Christian Bundy
Alexander Cobleigh
Henry
Daan Wynen