Add more comprehensive tests

[christianbundy]

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.

[christianbundy]

@black-puppydog for your pleasure I've pulled all of the dep PRs into this one, for a few reasons:

• ensure that they all work with manual testing
• ensure that they all pass these new tests together
• ensure that you remain sane, as far as I'm able to :heart:

[black-puppydog]

oh man, don't worry about my convenience. I was just amused by the timing of it :P

[christianbundy]

I think this one is good to go now!

[black-puppydog]

So, I built this and it runs. But my brain is too tired rn to really grok this. From what I see there, you do handle tests in the env, and don't just post willy-nilly into whatever ssb feed is handled on the machine already :+1:. but... how does this work if I'm running e.g. patchwork? I'll have to stop that, right?

It's 2am here... I'm going to bed. :stuck_out_tongue:

[christianbundy]

Added a comment to explain that, but go to bed! Talk to you tomorrow dude.

[cryptix]

In case you ever want to test against actual feed content, ssb-fixtures might be of interest. Staltz made it for performance benchmarks but a smaller dataset of say, 15 feeds and a couple hundred messages would also make for good test content.

[christianbundy]

That's a great idea @cryptix, thanks! Are there any tests that come to mind? I can imagine the fixtures being useful for a human browsing around, because you can tell when stuff "looks right", but I [pre-coffee] can't think of tests that I'd be able to write with them. Clarification: I'm sure there are tests to write with them, I just need help knowing what to test. :laughing:

[cryptix]

Hmmm... Your decision how wild to go with this but I'd use the fixtures to actually check that a thread is rendered (parse the generated html and use css selectors to check the content. In python there is beautifulsoup for this. I must believe npm has something similar)

Another thing that was a bit daunting in the blobs/preview work was testing that a reply actually ends up on a thread still. This could be done on an empty db but fixtures gives you a nice starting ground.

Other areas that come to mind /profile and its about information, nested threads, all the pagination, mentions, votes/popular. basically all the hairy bits of the models that you currently have to test against your live data/installation.

[christianbundy]

Oh, are the fixtures static? If so, that'd be easy to say "make sure that thread X has 10 comments, including this text". I'll poke at it the next time I've got some time. :rocket:

Any thoughts on this PR? I'm excited to get the dep PRs merged and then release the new version of Oasis.

[christianbundy]

(Trying to close all the dependency PRs in this branch. :pray: )

[cryptix]

Oh, are the fixtures static?

Yup. The repo contains a generated that should be deterministic but you also don’t need to run it again once you are fine with it, I think.

I’m not sure it contains nested replies but those could be created by oasis itself.

[christianbundy]

Been a couple days so I'm going to self-merge.

[black-puppydog]

sorry @christianbundy for dropping out here. been a crazy worky week so far.