convert tests into an abstract test suite module that other levelups can use

[max-mapper]

It would be really useful for us over at http://github.com/maxogden/dat to be able to e.g. require('abstract-levelup/tests') in the same way that there is an abstract-leveldown test suite.

Publishing a test suite as a module lets multiple modules all ensure compatibility since they use the same test suite. For example, level.js uses abstract-leveldown, and so does memdown and leveldown and others.

I liked @rvagg's idea of a test suite as a module so much that I copied the concept but for file storage: https://github.com/maxogden/abstract-blob-store

However, the levelup tests aren't a module yet. Someone needs to do the heroic task of converting the tests to use the tape API and make the tests require()-able

[kesla]

@maxogden I like to be your hero. I'll take a look at this!

[kesla]

I'm sitting on a plane for 8 hours tomorrow. This will be a great task for those hours.

[ralphtheninja]

Sweet! We need more programmers on planes :)

[dominictarr]

this would also be of use to level-sublevel

[rvagg]

Rather than putting the effort into this I'd like to understand why it's necessary to be building faux-levelups and what is it about levelup now that's preventing you from just reusing it?

I released level-updown yesterday, it's a leveldown backed by levelup, but it's also extensible so you can change its behaviour in creative ways and you end up with an unmodified levelup at the other end and the modifications are all in the leveldown layer (where it's actually easier). I'm using this for level-spaces to give me a namespacing solution where I get to operate on a complete, unmodified levelup but the backend does the translation to and from the namespaces of the original db.

I'd personally like to see more effort put in to creative ways to extend and adapt what we have instead of re-creating new versions that have subtle incompatibilities.

[mafintosh]

@rvagg Using the approach how would you add new method functionality? For example in dat we have an levelup compatible interface (see level-dat) but we also have a couple of extra methods (like createVersionStream()) exposed on the same instance

[rvagg]

@mafintosh I floated this idea for LevelUP a while back but didn't get any traction, I'd be interested to see how far it can get with LevelDOWN. Obviously there's additional functionality you can't achieve with just the LevelDOWN layer so you'd still have to resort to monkey-patching but I also don't see what you can't achieve by just taking LevelUP and monkey-patching or subclassing, why are you making a new one from scratch? If we can identify the problems that are leading you to have to reinvent this wheel then perhaps we can reengineer LevelUP to serve those purposes better. For instance, are we still hiding too much internal logic and data from extensions & subclasses? Should we split up internal functionality into more (pseudo) private methods on the prototype so you can extend it directly and reimplement the methods where you want to adjust the functionality.

[dominictarr]

also, there are elements of levelup you can reuse.
level-sublevel depends on the levelup/lib/codec and levelup/lib/read-stream for example.
there is furthur discussion over here:
#270

[dominictarr]

oh max already linked that discussion here, maybe he has a good point?

[max-mapper]

I still think we need to do this, because just because something has a compatible API it doesn't mean it is implemented correctly.

For example level-spaces does require('levelup') and returns a new instance, so the API is 100% compatible, but it still has bugs like this: https://github.com/rvagg/level-spaces/issues/3

If the test suite of level-spaces could have easily used an e.g. abstract-levelup test suite to check if it's levelup is 100% compatible with the stock levelup then it would have saved me a lot of headache today.

[mcollina]

👍. After having spent two hours fighting the problem, I think we need such a test suite. Unfortunately I have no bandwidth to help atm.