neography is a component that falls perfectly in the definition of what needs to be mocked when doing TDD.
Having an offline mode (think airplane-mode for iPads, or sqlite) that I could instantiate from a file and work only on memory could be a great help when testing and avoid setting multiple neo4j instances.
You can mock neography itself in your application, of course.
Neography is a database driver, it doesn't have much internal logic (there is some, but it's main purpose is still to reflect DB internals). I haven't seen people mocking database calls when developing database drivers (even though I took a part in development of at least 4 completely different drivers).
It's a problem of your application rather than neography to be mocked.
Yes, I agree. I just thought it would be more convenient to have an easier way to load complex graphs in a mock-able instance of neography. I thought of forking the project and doing it myself, unless there are any objections on principle... ?
@dimerman once again, Neography itself does not do any graph operations. All it does is making HTTP requests to neo4j endpoint. It doesn't store, doesn't traverse, doesn't cache persist whatsoever. It's all done by neo4j.
I'm not entirely sure what you want to do. Neo4j is a very lightweight package, it's a simple jar file, very portable and embeddable, not much less embeddable than sqlite. Not sure why one'd like to mock it. If it's about performance, try isolating tests first, that wat you can save time on mocking things away. I don't know many use cases for mocks, honestly.
You can do it yourself, of course...
But unless I understand your point correctly, there's not much benefit, and the overhead is quite significant.
it may be that I'm approaching my problem from the wrong angle: i am using neography as my lowest level component and all I want is to cook a system-wide set of tests. the fact that it's a thin proxy to the actual db is incidental and from my perspective not very relevant; I don't see past neography, so even though is as thin as it can be, every call ends up having the latency of an HTTP call + all that is involved past that. I look at neography as if it were a driver. I don't want to set a parallel database with a different port just for this purpose, and I don't want to be messing with my code to have alternative cases for testing.
the most economical alternative I could come up with was to mock/stub neography.
some people that work with mySql or Oracle, use sqlite for testing and inject the alternative JDBC driver for this purpose. sqlite is initialized with a file that has the schema, and you're ready to go.
I do not think what you are asking for is possible. Even assuming I could "load" the graph database from a file.
How would I mock a gremlin script or cypher query? These could be anything. I think this is best handled at the Application level with something like the VCR gem.
@ifesdjeen :i'm glad to provide some comic relief. I guess it's what you call "it's funny because it's true". I know of projects that used sqlite to speed up CI tests on logic that would otherwise go to the actual db (oracle), and thus to disk, making each test cycle unbearably slow.
@maxdemarzi : i wasn't thinking of stubbing complex queries, just the basic get_node(), get_relationship(). I agree it could become a slippery slope and become a bottomless tar pit. i'll have a look at the gems you mention...
It was mostly funny because replacing oracle with in-memory sqlite db for testing is like fixing a dam drain with a kitchen gag ;)
Really, try approaching your problem from another side. We're using neo4j for about 2 years already, and it's quite an important system component (otherwise why would we bring it in), tried many approaches, and the one you mention does not help much. If you don't believe or think I'm mistaken - try it yourself, and come back to tell how it was.
@ifesdjeen yeah, I tend to agree. I still feel uncomfortable going to the db each time I run tests. even if the footprint is nil, i can see it getting slower for every test case i add. if you have a better methodology to embed testing on a continuous integration rig, i'm all ears.
PS: the sqlite thing was useful when we tried to prevent regression. we had test cases that reproduced actual bugs, and a minimal db that helped bring the problem up.
Better methodology is to decouple your business logic from your database logic. That way you can use fixtures.
Leave the database logic for unit tests of database devs, and transport to driver devs.