-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add specs for ns datahike.api #596
Conversation
@@ -30,7 +30,7 @@ | |||
[{:db/id -1 :profile #"regexp"}]) | |||
|
|||
(is (thrown-with-msg? Throwable #"Unknown operation" (d/db-with db [["aaa" :name "Ivan"]]))) | |||
(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) | |||
#_(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) ;; todo: how to test incorrect spec now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment the specs are being checked when the tests are run, so db-with
already fails on the specs and it doesn't even get to the point where it would throw "Bad entity type".
The question is now if we want to to keep on checking the specs for testing or we should be able to have tests like this one here, which is good to have for documentation purposes in order to see what's happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if we were not using the specs in the tests the question would be where and how else we would use them. One option would be in development environments. Probably not production though as is would slow down the code, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think this is a common way to enforce contracts/spec like that, to activate them in development and debugging and turn them off in production. It really depends though also on the production environment, since they guard an interface to external access here. The main direct benefit of having specs at all in my opinion is to have automatically checked documentation for what the inputs should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this here is an edge case where we would have two guards. Ideally we could just tell that this spec check should be always on, not sure whether this is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I can't find any documentation about how it would be possible to automatically turn on instrumentation for development. It looks like it is always turned on manually by calling s/instrument
in the repl. There are libraries that are doing it differently, but they might have less features.
I would suggest removing the instrumentation for the tests for now and instead use the specs for generative testing in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that's another option. I could live with that as well, but I think I would still personally prefer removing the instrumentation from the tests entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with not instrumenting the specs but then probably no one ever uses them again:) So maybe we should have some kind of interface-test? Just an idea...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by 'interface-test'?
As mentioned above, I would like to use them for generative tests which would act like a check if the specs are correct as well as enable us to potentially discover bugs that we wouldn't have discovered otherwise. Is that what you mean as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'd say that's what I meant. But I would rephrase it a bit... the specs are basically defining our contract with the world and therefore we should keep some kind of test that this contract is not broken and works reliably.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have created issue #605 for this topic now. Feel free to change the wording or add stuff that you think is missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, might need another discussion on the dev integration. But then it would be ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did not go through in detail with the specs. But so far looks good to me. Thanks for finishing this long standing PR @jsmassa! Especially remarkable are the changes in the api-ns where you are using this raise-macro which is awesome, wondering who made this ... 🤔. I should have used this when rewriting the api-ns.
@@ -30,7 +30,7 @@ | |||
[{:db/id -1 :profile #"regexp"}]) | |||
|
|||
(is (thrown-with-msg? Throwable #"Unknown operation" (d/db-with db [["aaa" :name "Ivan"]]))) | |||
(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) | |||
#_(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) ;; todo: how to test incorrect spec now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you look into unstrument? Maybe we can stop the instrumentation for certain tests?
@@ -30,7 +30,7 @@ | |||
[{:db/id -1 :profile #"regexp"}]) | |||
|
|||
(is (thrown-with-msg? Throwable #"Unknown operation" (d/db-with db [["aaa" :name "Ivan"]]))) | |||
(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) | |||
#_(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"]))) ;; todo: how to test incorrect spec now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(st/unstrument)
(is (thrown-with-msg? Throwable #"Bad entity type at" (d/db-with db [:db/add "aaa" :name "Ivan"])))
(st/instrument))
Seems to work. Don't know if this works well because of the concurrency of the tests, though.
* Add Clojure Specs for the `datahike.api` namespace --------- Co-authored-by: Fabrizio Ferrai <[email protected]>
Renewal of PR #330