Knex 2.1.0 support

[taybin]

It looks like it should be easy to support with mock-knex.

[skubot]

It already works fine with [email protected]

[JeremyVanBiljon]

I'm having issues with [email protected] when using the current latest version of this library (0.4.11)

It seems that it won't work with any knex version above 2.0 due to a restriction set in the peer dependencies:

"peerDependencies": {
    "knex": "> 0.8 <= 2.0"
}

It works when using npm install --legacy-peer-deps to ignore the range of specified versions, but this is not optimal

[throrin19]

Same problem here. The peerDependencies is really annoying.

Normally, If we update knex, We don't do the npm install --legacy-peer-deps

[Fryuni]

There hasn't been any commit or message on any of the PRs since May. @jbrumwell do you need any help? Maybe a call for maintainers would be a good idea

[rage28]

@jbrumwell I've tested with knex 2.3.0 as well and it works fine.

[jbrumwell]

Removed the requirement for the version range, should not work as expect in 0.4.12 let me know if not. @Fryuni I haven't had a professional need for mock-knex in 4 years, I would be interested in discussing this. Always bugs me that I don't have time to get to these issues :)

[Fryuni]

@jbrumwell we ended up migrating to another library for mocking knex since we also needed some extra features (like testing if concurrent transactions are executed in isolation), so I also don't have any professional use for mock-knex anymore.

Although I like this API more for simple applications.

[jbrumwell]

@Fryuni :+1: Thanks for letting me know :)

[mlarcher]

Removed the requirement for the version range, should not work as expect in 0.4.12 let me know if not. @Fryuni I haven't had a professional need for mock-knex in 4 years, I would be interested in discussing this. Always bugs me that I don't have time to get to these issues :)

I'd be interested to know how you handle the db tests nowadays. Do you use a lite inmemory db ? Or another approach ?

[jbrumwell]

We use docker to test against postgres, MySQL etc

[Fryuni]

I'd be interested to know how you handle the db tests nowadays. Do you use a lite inmemory db ? Or another approach ?

I'm using the library knex-mock-client.

I found its API to be easier to extend to more complex scenarios. It also made easier to implement a feature that both libraries were missing, which is to test interleaving transaction contexts, as you can see here

[mlarcher]

I always loved the simplicity of not needing a real database when running the test-suite, even though I couldn't find much on the matter when googling. It seems a large majority of people don't go that way. And now even the creator of mock-knex does so. I guess we can't argue with such an overwhelming majority... There must be something wrong with mocking the db adapter. The thing that annoys me the most is that we need the full docker-compose shebang for unit-testing on alocal dev environment, wich has a price in term of performance / run time :-/

[throrin19]

For that, many solution can be found. When I work with mongoDB, we used a mock simulate the entire DB (using mongo-mock : https://www.npmjs.com/package/mongo-mock). In tests, we have isolation of our Database in memory (with documents, ...) and in the tests, we check if the request return correct documents according to the logic of the request.

The same with the elements in the database as soon as we manipulated it (via insert/update/delete).

For me, the better solution is this : in-memory test database with isolation for each tests (Otherwise, with parallel tests you can quickly have unwanted side effects to check if everything is going as you want).

Unfortunately, I could never find an equivalent library for knex or mysql or sql in general

[Fryuni]

I always loved the simplicity of not needing a real database when running the test-suite, even though I couldn't find much on the matter when googling. It seems a large majority of people don't go that way. And now even the creator of mock-knex does so. I guess we can't argue with such an overwhelming majority... There must be something wrong with mocking the db adapter. The thing that annoys me the most is that we need the full docker-compose shebang for unit-testing on alocal dev environment, wich has a price in term of performance / run time :-/

@mlarcher

There is a very valid argument for not mocking the database adapter. You won't know a query is truly working, the test can at most ensure that the query you wrote on the test is what gets generated.

For simple queries, you can review them manually to be sure that it is working, but this doesn't scale.

We use this to test simple CRUD operations where there are no joins or anything. And to test the transaction interleaving, as I mentioned above. When there is a more complex query, we test the actual execution of the database.

Like @throrin19 said, you don't actually need to run the real, production-ready database on a docker container for your unit tests. For example, if you use Postgres, you can probably do with something like pg-mem which implements most of the PG query logic but not the persistence, WAL, disaster-recovery, protocol, concurrency, etc.

Btw, @throrin19

Unfortunately, I could never find an equivalent library for knex or mysql or sql in general

I don't know any library that implements the SQL standard from ANSI, ISO, or Oracle, and neither the SQL extensions for MySQL as in-memory databases, but for Postgres there is the one I mentioned above. If you set your driver for pg on your tests it might be enough for you.

[mlarcher]

@Fryuni I believe that unit-tests should be fast and standalone, hence not require a real database. Testing that "the query is truly working" should be done in integration tests or end to end tests imho.

Also, when you use something like pg-mem, you diminish the "query is really working" thing, as it is not the real targeted db, so the guarantees you get from the tests are not that strong...

All things considered, it looks like an acceptable tradeoff, but for localDev it requires always running the tests in a docker container, which slows things down quite a bit