3 ms·

In nodejs I use mongo memory server[0] for unit testing. Would this be able to fill this gap in python? [0] https://www.npmjs.com/package/mongodb-memory-serve

In nodejs I use mongo memory server[0] for unit testing. Would this be able to fill this gap in python? [0] https://www.npmjs.com/package/mongodb-memory-server https://www.npmjs.com/package/mongodb-memory-server

davidlatwe 5y ago
Hmmm, better not using it for unit test I think. Had a quick look into that mongo memory server and it pull the real mongodb instance for testing so it’s solid. MontyDB in other hand is only a tiny in-completed replica (only had basic CRUD implemented, no aggregation and other fancy stuff). Could be used for a quick demo for application that requires MongoDB, which was part of my initiative back then.
- vorticalbox 5y ago
  Thanks, that's a shame I started a new project in python (Fastapi and mongodb) and was looking for something to fill that gap. This still looks awesome.
  - davidlatwe 5y ago
    Thanks !
- davidlatwe 5y ago
  > Could be used for a quick demo for application that requires MongoDB If the demo or production only requires those basic operations of course. Those implemented ops are testing against to real MongoDB, so should be good enough for basic usage.
  - watermelon0 5y ago
    IMO unit tests can be done against any implementation, even a mock one, so using Monty would be beneficial, if it supports all you need. However, you need to have integration tests, to ensure that such implementation behaves the same as the MongoDB version you have in the production. Such tests only need to be run when you change the implementation or upgrade production MongoDB.
gchamonlive 5y ago
That is not a unit test anymore. No matter where you are writing your database. A unit test should test the unit and not rely on any dependency.
- slver 5y ago
  That means adapters and drivers are not unit testable. This differentiation is quite pointless though. If you can spawn the dependency in memory at no cost then why not. Also not using dependencies is not the point of a unit test. Almost everything has dependencies.
  - hinkley 5y ago
    All of the logic in the driver can be unit tested. Actually talking to the back end is functional testing. It's a common mistake that people think that HTTP implementations can't be unit tested too, but the truth is a bit more complicated. These libraries are essentially a wire protocol and people think of them as 'wire-protocol' instead of 'wire, protocol'. If you think of it instead as a codec with IO, then you write the codec separately and you can fully test the codec without mocking any IO at all. It's nearly tautological that code that is written to be unit tested can be unit tested, and code that isn't cannot be. And because people want to get their code 'working' and then prove that it works, they are battling uphill to get good tests written, because good tests can't be written. And then some people use this as confirmation bias for why they shouldn't have to write tests.
    - slver 5y ago
      You can’t test the logic without the parts that interpret the logic. Your mock will fail if I change the name of a alias in my query. A database won’t. Don’t confuse how it’s done with what is done.
      - hinkley 5y ago
        Don’t confuse functional tests with unit tests. Both are necessary for systems with side effects (ie most systems)

davidlatwe 5y ago

Hmmm, better not using it for unit test I think. Had a quick look into that mongo memory server and it pull the real mongodb instance for testing so it’s solid. MontyDB in other hand is only a tiny in-completed replica (only had basic CRUD implemented, no aggregation and other fancy stuff). Could be used for a quick demo for application that requires MongoDB, which was part of my initiative back then.

vorticalbox 5y ago
Thanks, that's a shame I started a new project in python (Fastapi and mongodb) and was looking for something to fill that gap. This still looks awesome.
- davidlatwe 5y ago
  Thanks !
davidlatwe 5y ago
> Could be used for a quick demo for application that requires MongoDB If the demo or production only requires those basic operations of course. Those implemented ops are testing against to real MongoDB, so should be good enough for basic usage.
- watermelon0 5y ago
  IMO unit tests can be done against any implementation, even a mock one, so using Monty would be beneficial, if it supports all you need. However, you need to have integration tests, to ensure that such implementation behaves the same as the MongoDB version you have in the production. Such tests only need to be run when you change the implementation or upgrade production MongoDB.

gchamonlive 5y ago

That is not a unit test anymore. No matter where you are writing your database. A unit test should test the unit and not rely on any dependency.

slver 5y ago
That means adapters and drivers are not unit testable. This differentiation is quite pointless though. If you can spawn the dependency in memory at no cost then why not. Also not using dependencies is not the point of a unit test. Almost everything has dependencies.
- hinkley 5y ago
  All of the logic in the driver can be unit tested. Actually talking to the back end is functional testing. It's a common mistake that people think that HTTP implementations can't be unit tested too, but the truth is a bit more complicated. These libraries are essentially a wire protocol and people think of them as 'wire-protocol' instead of 'wire, protocol'. If you think of it instead as a codec with IO, then you write the codec separately and you can fully test the codec without mocking any IO at all. It's nearly tautological that code that is written to be unit tested can be unit tested, and code that isn't cannot be. And because people want to get their code 'working' and then prove that it works, they are battling uphill to get good tests written, because good tests can't be written. And then some people use this as confirmation bias for why they shouldn't have to write tests.
  - slver 5y ago
    You can’t test the logic without the parts that interpret the logic. Your mock will fail if I change the name of a alias in my query. A database won’t. Don’t confuse how it’s done with what is done.
    - hinkley 5y ago
      Don’t confuse functional tests with unit tests. Both are necessary for systems with side effects (ie most systems)