Unit-testing with Midje is a great experience, but now I need to test some code which interacts with the filessytem. Specifically, the code builds a data structure representation from a local directory layout.
Something that comes to mind is creating directories and files in /tmp, which then have to be cleaned up after the tests. I probably could make it work but it would be much better if there were a Right Way to do it.
What is the preferred way to test filesystem code, in Clojure or more generally?
I'm not sure whether there's specifically something that can help you with filesystem stuff already, but setup and teardown can be performed using background or against-background (if you need lexical scoping).
The general idea is similar to setup/teardown in other languages, you'd do something like this:
(require '[clojure.java.io :as io])
(background (before :facts (io/make-parents "parent/child/file")
:after :facts (map io/delete-file (reverse (file-seq (io/file "parent")))
(facts "About something or other
...)
Before your facts, this will create the parent and child directories (not the file - you can add in a spit or something if you need the file too). Then after your facts it:
recursively gets a list of the contents of the parent directory (using file-seq)
reverses it (because we can only delete empty things, so must start at the bottom of the directory tree)
applies the delete-file function to each directory in the tree
The code there to create and delete files may not be the best (I'm new to this!), but the approach for setting up and tearing down stuff in Midje tests is sound.
Things to note:
Be careful with symlinks in your tree when using this approach, you could get stuck in a loop.
The :after syntax instead of using an (after) macro is there to ensure the teardown occurs even if the test throws an exception.
You can do the setup/teardown after a subset of facts in a single namespace by wrapping them with (against-background) and doing the same thing instead.
References:
https://github.com/marick/Midje/wiki/Setup,-Teardown,-and-State
https://github.com/marick/Midje/wiki/Background-prerequisites
Related
I have the following code that loads edn data from my resources folder:
(defn load-data
[]
(->> (io/resource "news.edn")
slurp
edn/read-string))
I'd like to test this by mocking out the file reading part, so far I have this:
(deftest loading-data
(is (= (edn/read-string (prn-str {:articles [{:title "ASAP Rocky released" :url "http://foo.com"}]})) (load-data))))
But I know this very flaky test because if the edn file name changes or it's contents or updated, the test will fail. Any ideas?
You can mock out a call to function with with-redefs, that "Temporarily redefines Vars while executing the body". E.g.,
(deftest load-data-test
(with-redefs [slurp (constantly "{:a \"b\"}")]
(is (= (load-data) {:a "b"}))))
This way the slurp in load-data in the scope of with-redefs returns "{:a \"b\"}".
What about this function are you wanting to gain confidence for? Are you worried that news.edn won't exist? Are you worried slurping and or edn reading won't work on a resource?
My advice is to test your separate concerns separately
If you're worried about news.edn not existing assert against it's existence
If you're worried about the rest of the function not converting from edn add a new signature to accept a resource then provide another resource at test time to assert against
If you're worried about the shape of the file maybe have a test that runs against the data before it's put in news.edn
Then when you come back to these tests years later you'll see clear reasons for failures instead of a test that fell over because of N possible reasons that are unknown till debug time
As other's have suggested: Mock less things.
It might be a reflex you learned from building Java tests.
If you have composed your functions correctly, you can test them individually without the need for side-effects (like reading a file).
If you mock slurp in your example, you are not testing anything meaningful: You would essentially test if the standard function edn/read-string works as intended.
Rewrite your load-data to accept the name of the file to load as argument (and later call it with news.edn in your "main"). This makes it way more functional and this way you can easily test load-data the way you test it right now, but you pass down some test-news.edn from your test resources. And there is no need to mock anything for the happy path.
This way you can also write test for other scenarios: what if the file is missing? Or the .edn file is malformed. What if you pass some resource that loads forever? etc.
Suppose we wanted to write a cheating quine in clojure, we could do:
(ns cheating-quine)
... stuff here doesn't really matter ...
(println (slurp *file*))
Now, this does not work in Lein Figwheel because the value of file ends up being something like /tmp/form-init########.clj, and contains bootstrapping code of some sort.
Question: how can we get this "cheating" quine to work in clojurescript?
Note: the goal is NOT to write a quine. The goal is to write a cljs program which has access to the file it's defined in. This whole "cheating quine" thing is trying to explain the problem better then my previous failed attempt of
Clojure + Clojurescript: Macro to read code of current file
A cheating solution is to distribute the source code (e.g. put it in resources and serve it as a file) and compile a bootstrap to load and execute code, and get it to pull down your file, and in the file load the same file... that way it can do a HTTP request for the code that is currently running, and execute it. This is essentially how ClojureScript browser REPLs such as http://clojurescript.io/ work... They compile and execute incoming code on the fly. clojuresript.io is a good working example of ClojureScript bootstrapping if you are interested in it, but a word of caution, there is quite a lot going on so expect to invest quite some time :)
I have just begun playing with ClojureScript and I'd like to collect all CSS files into a single folder (out/css). I found leiningen-less and with the following config I get the compiled CSS files into the correct location:
:less {:source-paths ["src/less"]
:target-path "out/css"}
I can't find any documentation on how I can handle the ordinary CSS files (e.g. the file for resetting defaults, css/reset.css). Basically I want the equivalent of cp css/*css out/css.
I did find lein-resource but it does a bit more than I require (pass things through stencil) and more importantly it through an UnsupportedOperationException on my with what I thought would a be a valid configuration:
:resource {:resource-paths ["css" {:target-path "out/css"}]}
Please englighten me!
For your particular use case just rename reset.css to reset.less. less should be able to read CSS without problems.
For more advanced frontend tooling maybe consider adding something like make/grunt/etc. More complexity but more power & flexibility.
I think better and easy solution would be that you write a function that uses clojure.java.io library functions and integrate them with lein-less "compiler" fork, so this is my internal function proposal:
(defn your-fn[]
(remove-folder "./out") ;; => you have to do how to make that fn following io lib doc
(copy-folder "./css ./out") ;; ;; => you have to do how to make that fn following io lib doc
(run-compiler :javascript
{:project-root "your-project-root/"
:source-paths ["less"]
:target-path "out"})))
PS: note that you need to call this fn from your clojurescript compilation process, BTW I didn't know if there is a way for that :)
I'm looking for a way to get a list of all the current namespaces in the current project, i.e. excluding namespaces in imported jars, libraries etc.
Currently I have found bultitude which seems pretty close to what I need and can do:
(bultitude.core/namespaces-on-classpath)
However this returns all the namespaces on the classpath, including "clojure.core" etc. rather than just the ones in the current project.
Is there an easy and reliable way to solve this?
what about the tools.namespace lib? there are the api:
find-namespaces-in-dir
find-namespaces-in-jarfile
find-namespaces-on-classpath
Well, it depends.
The idea behind bultitude is to provide a list of namespaces on the classpath. Any .clj files on that classpath will be accounted for.
You can, however, look up only namespaces beginning with a certain prefix. Usually projects also begin with a certain prefix in their namespaces. Would that work? Example from the readme:
user=> (b/namespaces-on-classpath :prefix "bultitude")
(bultitude.core-test bultitude.core)
If that isn't good enough, you can try to give it a classpath that only your files are on, but that may not work so well.
user=> (b/namespaces-on-classpath :prefix "bultitude" :classpath "src:test")
(bultitude.core bultitude.core-test)
I am trying to go through the process of creating a jar file from a simple clojure file. Below is my clojure code:
(ns app.first (:gen-class))
(refer 'clojure.core)
(defn -main [& args] (println "this program worked!"))
I am using these instructions to create the jar file: http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips
I see the error "java.io.FileNotFoundException: Could not locate app/hello__init.class or app/hello.clj on classpath: (NO_SOURCE_FILE:0)" when I try to complete the (compile 'app.first) step.
The only difference between my attempt and the link is the name of my file (first.clj instead of hello.clj).
Can anyone see where I am going wrong? Or for that matter, all I want to do is learn how to create a jar from a clojure file, so if anyone knows of a better/easier way to do that, let me know.
It's better to use Leiningen for such tasks - it allows to maintain dependencies, and packs all necessary components into jar file
I'm rusty on this, but I heard about other people with similar problems.
I think it's helpful to remember that the classpath you indicate points to the root of your class tree, and package names end up creating subdirectories within that tree. Awkwardly stated, but I hope you get the idea. Thus, I think you need to do some kind of gymnastics with creating directories to match the "app.first" -> "/app/first" hierarchy.
Sorry, that's as close as I come to a sensible and useful answer. Hope this helps you.
EDIT:
The Prime Directive of Computer Science: It only works if you do everything right! I spent almost 10 minutes fiddling with this but was finally successful.
Here's what I needed to do to get your program to compile:
created a directory app, and within that, first.clj with your code.
checked for the *compile-path* by doing (pr *compile-path) within Clojure. It said "classes".
created a second directory classes parallel to app.
in the shell, did export CLASSPATH=.:./classes
in Clojure, did (compile 'app.first)
... and I found a bunch of class files in classes. JARring those should be a snap.
I found it very helpful to run (doc compile) because that reminded me of the requirement to have a directory to satisfy the requirement for a *compile-path*.