I am having trouble to use test.check together with normal tests. I tried the whole day to figure out what is going on, but I am still not sure.
This is what I have now:
(deftest user-can-only-be-inserted-once
(;normal test))
(defspec insert-one-user-should-let-me-retrieve-that-one-user
gen-quantity
(prop/for-all ; test.check test))
Now, as long as I execute "lein test" from the console after each change in the test file it works as expected. However, running tests from the cursive repl or with the quickie plugin via "lein quickie" the repl will reload the namespaces not correct.
The effect is that, whenever a test fails and I fix that test it will still fail in the repl, so it looks like something is not working correctly there.
If anyone has an idea how to fix this, I'd be happy to hear it. I would also like to hear if someone has a different setup which combines normal tests and test.check or if this is not intended to work at all.
Thanks,
Sven
Update Actually I found out that the problem is not the combination of normal and test.check but the fact that I am trying to check an assertion is throw on a specific case. In normal test you would do this with (is (thrown? Assertion (function... But when I try this in test.check it just fails.
If I understand your update correctly, your test expects that the exception is thrown. If the exception does not occur, then the test should fail.
If so, then you will need to write the property in defspec to catch the exception, return it as a value, and verify that the exception occurs.
You could do something like this:
(defn catcher [f]
(try (f)
(catch Throwable t t)))
(defspec some-specification-name
(prop/for-all [...generator-bindings...]
(not-nil? (catcher (my-function generated-values)))))
Related
Simple question. I'm trying to test in midje if my method triggers an exception. I could only find something like the following in the midje documentation.
(fact "Should throw a RuntimeException"
(my-method! anything) =throws=> (RuntimeException.)
Thanks.
Never mind. I found it.
(fact "Should throw a RuntimeException"
(my-method! anything) => (throws RuntimeException)
That works for me.
I'm working on a library that finds dependencies within the source tree during application startup and I'm trying to write an integration test to ensure it works. I've got fixture files in my test namespaces, and the test starts and succeeds just fine.
To be sure that the tests don't affect future runs, I added an "after" handler (in midje) that uses remove-ns to remove the test fixture namespaces.
On the next load, the tests fail because the namespaces are missing.
It seems as if remove-ns not only removes the namespace, it makes it impossible to use require to load it into the same running VM afterwards. I note that there is a "use with caution" note on remove-ns with no explanation.
I've verified that manually running require does not, indeed, seem to be able to re-load a namespace that has been removed:
user=>(test.util.fixtures.A/f)
{:item 1}
user=> (remove-ns 'test.util.fixtures.A)
#<Namespace test.util.fixtures.A>
user=> (test.util.fixtures.A/f)
ClassNotFoundException test.util.fixtures.A
user=> (require 'test.util.fixtures.A)
nil
user=> (test.util.fixtures.A/f)
ClassNotFoundException test.util.fixtures.A
Anyone understand why this is happening?
I traced through the source, and it ends up that require calls load-libs, which in turn calls load-lib, which in turn checks a global atom (the line is loaded (contains? #*loaded-libs* lib)).
Reading further, it seems that once something is loaded, you can specify the :reload option to the library loader. Now I remember seeing the :reload, so the solution was to put :reload in the require:
user=> (require 'test.util.fixtures.A :reload)
nil
user=> (test.util.fixtures.A/f)
{:item 1}
I'm trying to create a text based Clojure game (inspired by Land of Lisp).
(def *nodes* {:living-room "you are in the living-room. a wizard is snoring loudly on the couch."
:garden "you are in a beautiful garden. there is a well in front of you."
:attic "you are in the attic. there is a giant welding torch in the corner."})
(defn describe-location [location nodes]
(nodes location))
The code is running in the REPL but if I saved the code to a file and trying to run:
(describe-location :attic *nodes*)
I got:
Exception in thread "main" java.lang.IllegalArgumentException: Wrong
number of args (1) passed to: user$describe-location (wizard-game.clj:
0)
What I'm doing wrong?
Here is the file: http://dl.dropbox.com/u/3630641/wizard-game.clj
You have too many parentheses. Instead of (describe-location(:garden *nodes*)), you want (describe-location :garden *nodes*).
Remember that the name of the function goes after the open paren, not before: you were calling (:garden *nodes*) and then calling describe-location on the result, which failed because describe-location wants two arguments, not one.
one potential problem is that the version of the function that is loaded into the repl in the 'user' name space may not be the one you expect, so you may want to (load "wizard-game.clj") into a fresh REPL. though many people are using leiningen for this these days, except for the good number of people using maven directly.
first give your're game a namespace
(ns com.me.myGame
....)
then you can load it into the repl by running
(use 'com.me.myGame)
and call the functions by either their name-space-qualified names
(com.me.myGame/describe-location :attic)
or from the repl switch into that namespace:
(in-ns 'com.me.myGame)
(describe-location :attic)
or you can use leiningen to create your project and name-space automatically.
leiningen is worth it in this case because it just took me longer to write this sentence than to make a project with lein. There are a lot of good tutorials for leiningen.
lein new wizard-game
and then edit src/wizard-game/core.clj. this will let you add dependencies later with out fuss if when the project grows to world-famous-success
I'm playing with someone else's code by examining it in the repl.
It keeps calling System/exit, which brings down my repl. This is infuriating.
In all the code I have access to, I've mocked the calls out.
But it's also calling some library code I don't have the source to, both java and clojure, and this occasionally causes exits too.
Is there any way to catch these calls globally, so that an attempt to call them doesn't kill the repl thread? Ideally it would just throw an exception instead.
I think in java I could install a new SecurityManager to get this effect, but I've never done it
there seems to be something in that line here:
http://jroller.com/ethdsy/entry/disabling_system_exit
So I'm thinking something like:
(System/setSecurityManager (SecurityManager.))
only I somehow need to attach
public void checkPermission( Permission permission ) {
if( "exitVM".equals( permission.getName() ) ) {
throw new ExitTrappedException() ;
}
}
My best shot so far is:
(System/setSecurityManager
(proxy [SecurityManager] []
(checkPermission [p]
(when (= "exitVM" (.getName p))
(throw (Exception. "exit"))))))
or maybe
(System/setSecurityManager
(proxy [SecurityManager] []
(checkExit [n] false)))
But they both just destroy the repl
Or is there a better way of doing this?
Use AspectJ and intercept all Calls to System.exit() with a no op.
But you are right, just configuring the security manager would be saner.
You can also use clj-sandbox to restrict code you don't trust.
This one works for me in both, Clojures simple REPL, and in the Lein REPL, too
(def SM (proxy [SecurityManager] []
(checkPermission
[^java.security.Permission p]
(when (.startsWith (.getName p) "exitVM")
(throw (SecurityException. "exit"))))))
(System/setSecurityManager SM)
Ah. Even in the Cider REPL in Emacs.
The name is actually "exitVM.n", where n is the numeric exit code passed to System/exit
I still have an issue to extend this security manager. Surprisingly many Clojure functions call the security manager, and thus, when used inside of it, give an infinite loop, aka StackOverflowException.
(For the latter I opened anothe question: Security Manager in Clojure )
You can try this: http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)
I have a little script
(use
:reload-all
'com.example.package1
'com.example.package2
'com.example.package3
'com.example.testlib)
(run-tests
'com.example.package1
'com.example.package2
'com.example.package3)
that I use to quickly reload everything and fire off the unit tests.
trouble is that each time (deftest ... ) is evaluated as the files are read an additional test is created so after working hard all day each test is now being run 103 times, eek!
There is a flag *load-tests* which determines the behaviour of deftest. (doc deftest) seems to implicate that setting this flag to false could solve your problem.