MockDatabase getting wrong results
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 9.9k
- Forks
- 735
- Avg merge
- 6h 36m
- Merged PRs (30d)
- 8
Description
Description
When using a MockDatabase to retrieve a value that we want to not exist, it gives us the wrong value. For example, if I have in it a Product with id 1 and ask for Product with id 2, it gives me the Product with id 1 instead of not returning a product at all
Steps to Reproduce
Let's take for example, https://github.com/SeaQL/sea-orm/tree/75f7d4fa57aaeaeee88ca43dda99ed602cdcc930/examples/axum_example :
If we have this test which adds a Post with id 1 and we ask for id 2:
diff --git a/examples/axum_example/service/src/query.rs b/examples/axum_example/service/src/query.rs
index e8d2668..a302cea 100644
--- a/examples/axum_example/service/src/query.rs
+++ b/examples/axum_example/service/src/query.rs
@@ -24,3 +24,22 @@ impl Query {
paginator.fetch_page(page - 1).await.map(|p| (p, num_pages))
}
}
+
+#[cfg(test)]
+#[tokio::test]
+async fn test() {
+ use sea_orm::MockDatabase;
+
+ let db = MockDatabase::new(sea_orm::DatabaseBackend::MySql)
+ .append_query_results([vec![post::Model {
+ id: 1,
+ title: String::from("abc"),
+ text: String::from("bla"),
+ }]])
+ .into_connection();
+
+ let post = Query::find_post_by_id(&db, 2).await;
+ println!("{:?}", post);
+
+ assert!(post.unwrap().is_none());
+}
and try to run it with cargo test -p axum-example-service --features axum-example-service/mock we will get an error
Expected Behavior
Test runs with no issue
Actual Behavior
running 1 test
test query::test ... FAILED
failures:
---- query::test stdout ----
Ok(Some(Model { id: 1, title: "abc", text: "bla" }))
thread 'query::test' panicked at service/src/query.rs:44:5:
assertion failed: post.unwrap().is_none()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
query::test
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass `-p axum-example-service --lib`
As we can see, it returns Post with id 1, even though we asked for Post with id 2
Reproduces How Often
Always
Workarounds
None as not testing for this case is not really a workaround but rather making a test suite incomplete
Reproducible Example
Example provided above as it is very simple
Versions
sea-orm-axum-example v0.1.0 (/tmp/sea-orm/examples/axum_example)
└── axum-example-api v0.1.0 (/tmp/sea-orm/examples/axum_example/api)
├── axum-example-service v0.1.0 (/tmp/sea-orm/examples/axum_example/service)
│ ├── entity v0.1.0 (/tmp/sea-orm/examples/axum_example/entity)
│ │ ├── sea-orm v1.1.5 (/tmp/sea-orm)
│ │ │ ├── sea-orm-macros v1.1.5 (proc-macro) (/tmp/sea-orm/sea-orm-macros)
│ │ │ │ ├── sea-bae v0.2.1 (proc-macro)
│ │ │ ├── sea-query v0.32.2
│ │ │ │ ├── sea-query-derive v0.4.2 (proc-macro)
│ │ │ ├── sea-query-binder v0.7.0
│ │ │ │ ├── sea-query v0.32.2 (*)
│ └── sea-orm v1.1.5 (/tmp/sea-orm) (*)
├── entity v0.1.0 (/tmp/sea-orm/examples/axum_example/entity) (*)
├── migration v0.1.0 (/tmp/sea-orm/examples/axum_example/migration)
│ └── sea-orm-migration v1.1.5 (/tmp/sea-orm/sea-orm-migration)
│ ├── sea-orm v1.1.5 (/tmp/sea-orm) (*)
│ ├── sea-orm-cli v1.1.5 (/tmp/sea-orm/sea-orm-cli)
│ │ ├── sea-schema v0.16.1
│ │ │ ├── sea-query v0.32.2 (*)
│ │ │ └── sea-schema-derive v0.3.0 (proc-macro)
│ ├── sea-schema v0.16.1 (*)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with examples/axum_example/service/src/query.rs and run cargo test -p axum-example-service --features axum-example-service/mock using the reproduced test. Trace the MockDatabase query behavior for a requested id that is absent from the appended result, then add coverage for the missing-record case. Done means the test passes and the query returns None rather than the existing Product.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- database, testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100