I’m very excited by this: Ran 1162 tests containing 1162 assertions in 35134 msecs <— That’s one of the World Singles suites of Expectations, run via Boot instead of Leiningen.

what elapsed time is normal for that suite?

with Leiningen? About 65000ms

oh wow, that's great

Well, 65s on the first run and 37-45s on the second run.

it would be interesting to run your tests in incremental mode

boot watch test

do you do AOT for the tests?

Nope.

We AOT one namespace only. We specify that with :aot in project.clj (what’s the equivalent in Boot?)

there is an aot task

which you can add to the pipeline

boot aot -n foo.bar test

or (boot (aot :namespace #{'foo.bar}) (test))

in the repl

@micha: Thanks. That works. I just need to remember to compose all these things

haha yep

So my build.boot file requires boot-expectations and I have a testing task to set up the test dependencies etc, and boot testing expectations works as expected, and I can also do boot testing repl and get a REPL where (boot (expectations)) runs the suite as expected...

…however, in that REPL (doc expectations) returns nil (without printing anything)

Even tho’ boot expectations -h from the command line does show the docstring.

can you paste the build.boot of the project where you're running boot repl from?

No, it includes all sorts of World Singles stuff.

ah ok

what happens if you do (meta #'expectations) in the repl?

do you see the docstrings in there?

Ah, if it helps, (doc expectations) works in bare boot repl but not in boot testing repl

This is the testing task (nothing proprietary in it:

(deftask testing
  "Provide testing execution context."
  []
  (with-pass-thru fs
    (set-env! :source-paths #{"test"}
              :dependencies #(into % '[[expectations "2.1.3" :scope "test"]
                                       [javax.servlet/servlet-api "2.5" :scope "test"]
                                       [org.clojure/test.check "0.8.2" :scope "test"]]))
    (require '[expectations :as e])
    (let [disable-run-on-shutdown (resolve 'e/disable-run-on-shutdown)]
      (disable-run-on-shutdown))))

hm interesting

Here’s the meta output:

{:boot.core/task true, :line 15, :column 1, :file "seancorfield/boot_expectations.clj", :name expectations, :ns #object[clojure.lang.Namespace 0x529f2fa5 "seancorfield.boot-expectations"], :doc "Run Expectations test in a pod.\n  \n  There are no options for this task at present.\n  \n  Keyword Args:\n    :help  bool  Print this help info.", :arglists ([& {:as *opts*, :keys [help]}]), :argspec [[:short-opt "-h" :id :help :long-opt "--help" :required nil :desc "Print this help info." :parse-fn #object[boot.cli$parse_fn$fn__86 0x2a41290c "boot.cli$parse_fn$fn__86@2a41290c"] :assoc-fn #object[boot.cli$assoc_fn$fn__96 0x35bf5269 "boot.cli$assoc_fn$fn__96@35bf5269"]]]}

i don't see anything in there that looks like it would affect the docs

:doc is in there

ah maybe it's some interaction with the repl

i wonder if this is an obscure bug in nrepl or clojure.repl maybe

So here’s another question… Since cider-jack-in seems to want to do boot repl, is there a way to override the behavior of the repl task so it sets some special stuff up?

sure, you can (let [orig-repl repl] (deftask repl ...

then you can call orig-repl in your task

Hahaha… OK… Sneaky!

you can use all the programming tricks now

💥

you can also do alter-var-root if you want

might be cleaner that way

The let trick doesn’t work… I get clojure.lang.ExceptionInfo: repl already refers to: #'boot.task.built-in/repl in namespace: boot.user so I assume I need an ns-unmap as well?

ah right yeah

also tasks have a special binding, *opts*

like for example:

(deftask foo
  [a asdf bool "Enable asdf behavior."]
  (with-pass-thru [_]
    (prn *opts*)))

if you do boot foo -a you will see {:asdf true}

you'll probably be able to use that with clojure.core/apply if you choose to wrap the repl task

Hmm, I can’t seem to unmap that symbol...

Listing out publics, interns, and aliases and I don’t see repl in any of those...

hm, it's referred into the boot.user namespace

Yeah, found it in ns-refers...

maybe like (ns-unmap (the-ns 'boot.user) 'repl) or something?

maybe it's not picking up the right ns?

Nope. I still get that error.

Maybe alter-var-root is the right approach at this point

strange, i've used the ns-unmap trick before

With repl?

not with repl, no

This finally did the trick:

(def orig-repl repl)
(deftask ws-repl
  "World Singles REPL task."
  []
  (System/setProperty "lein.profile.repl" "true")
  (orig-repl))
(alter-var-root #'repl (constantly ws-repl))

I couldn’t get (apply orig-repl *opts*) to work.

right, you need to unroll the map into a seq of key/vals

(apply f (mapcat identity *opts*))

because f expects kwargs

which are like an unzipped map kind of

But I need to specify all the same args to ws-repl that I would otherwise want to pass to repl, yes?

As it is, boot ws-repl -s just starts a regular interactive REPL, not a server

ah right yes

I think I’ll just give in and use customize-variable in Emacs

If I have a task in BOOT_HOME/profile.boot and a redefinition of that task in {project}/build.boot, I assume that’s safe and reasonable?

Ah, I get a warning it was overridden. That’s acceptable.

@seancorfield re: customizing repl, this is what i've done in that situation:

(alter-var-root #'repl
                (fn [old-repl]
                  (fn [& args]
                    ;; Do stuff here before running REPL
                    (apply old-repl args))))

oh wohops, sounds like you're doing that exactly already

Yeah, it did not behave the way I expected (nor the way @micha expected either, it seems).

I ended up following the CIDER REPL notes on the wiki and I’ll update my Emacs Live config to customize the setting...

Is it possible to do multi-version testing with Boot? We normally test against Clojure master as well as a particular version.

Seems like I’d have to run Boot twice and use the BOOT_CLOJURE_VERSION env var for that?

Hmm, that won’t work unless the Sonatype repo is available to Boot directly since it can’t find the SNAPSHOT of Clojure to start itself up...

It’s not a big deal but it was a nice to have

@seancorfield you can use any version of clojure in your pod

just add the version you want to the pod dependencies

so you can make any number of loss pools and run your tests in parallel in all the pod with different versions of clojure

i mean pod pools

not loss pools, autocorrect

pods can have a different version of clojure than the main one

OK, given boot-expectations already uses pods I’ll have to figure out how to pour in different versions of Clojure. Our test suite won’t actually run in parallel but that’s also an interesting option.

yeah you can run the testsn series too

Given boot-expectations creates a pod from the current environment but adds expectations and tools.namespace dependencies, how would you recommend I deal with changing the Clojure dependency? Define an option on the task that lets you override the default Clojure version?

that sounds like a good way to do it

(mapv (fn [[artifact version]] (if (= 'org.clojure/clojure artifact) [artifact new-version] [artifact version])) (core/get-env)) ; like so?

Is it considered good practice to expose task dependencies? boot-expectations currently relies on expectations 2.1.3 but the user might want a different version — should I expose an option to alter that too?

ther eis a function you can use

What happens if the user’s project env already has a tools.namespace dependency and I add a new one for my pod?

boot.pod/dependency-loaded?

so you can do like this:

`(defn pod-deps []

oops

(defn pod-deps []
  (remove boot.pod/dependency-loaded? '[[foo "1.2.3"] ...]))

that dependency-loaded? function will return true if the dependency is already on the classpath

Interesting… OK...

that could be true though if it's a transitive dependency

which you may or may not want in this case

like if the project has a dependency which in turn depends on foo

if the project already has a dependency on tools.namespace i think the first one wins

like the first one in the dependencies vector

boot show -p is pretty impressive. It seems Selmer and Expectations don’t like each other much right now…

I think I’m in love with boot watch build…

…where build is (comp (pom) (jar) (install)).

Uh-oh! My colleague(s) are here...

boot-expectations 1.0.0 is available: https://clojars.org/seancorfield/boot-expectations — you can include/exclude namespaces via regex; you can specify the version of Clojure to use in your tests; you can see namespaces as they finish "expecting".

@seancorfield: 👏

how are expectations different from assertions?

I find the syntax more natural and it suits BDD well...

http://jayfields.com/expectations/

We use Expectations for the majority of our unit tests at World Singles.

We only use clojure.test for our WebDriver tests since they’re side-effecty and assert-y.

We even "expect" clojure.test.check results in some of our tests.

https://www.refheap.com/112923 — Expectations using test.check

reads and learns

and reads more

seems much simpler to setup than clojure.test

Assertions feel very "imperative" to me: do something, assert the current state, so something else, assert the new state.

Expectations feel more "functional": expect this value/condition when you evaluate this expression.

yeah i see what you mean, well thanks for the boot task, it will come in handy!!

When doing a plugin, how can I see what is in the fileset ? ex. I have :

(core/deftask my-task []
  (core/with-pre-wrap [fs]
    ;; how can I see what is in fs ?
    (util/info "Task files : " (seq (core/input-files fs)))
    fs))

@nha: the show task has a -f/--fileset(?) option

if there are no files printed with your snippet there simply are no input files (could that be?)

@martinklepsch: There should be files, but https://github.com/boot-clj/boot/blob/44f9b8989310e6c30356f0455c97abe689f6b47c/boot/core/src/boot/task/built_in.clj#L183 will definitely help

@nha: what you can also do is just inspect the fileset as a record. e.g. (-> fs :tree keys) will give you a list of paths of files in the fs

Ah interesting, thanks

the values of the map in :tree are the corresponding TmpFile records then

I tried (keys fs) but it failed to print also, did not know about :tree. That should get me started

@nha: are you on 2.5.0 btw?

Boot App Version: 2.3.0
Boot Lib Version: 2.3.0
Clojure Version:  1.7.0

I think the (with-pre-wrap [fs] ...) style is new with 2.5.0

ls

oops sorry

before it was just (with-pre-wrap fs ...) so that might be why it's not properly printing anything

right. I was also missing the boot.properties file.

unless it is not needed for plugins ?

(I see none in https://github.com/adzerk-oss/boot-template )

@nha: it's not required but can be used to pin boot on a per project basis

@martinklepsch: Thanks for your help

@nha: you're welcome

Hi people I'm getting this error

Load failed: Jsloader error (code #0): Error while loading script /cloject.out/cloject/main.js?zx=2fluunlj7n0y

My build.boot starts with:

(set-env!
  :target-path "static"
  :source-paths #{"src"}

and in src/cloject.cljs.edn it contains:

{:require [cloject.main]
 :compiler-options {:asset-path "/static/cloject.out"}}

Oh and the error occurs, on reload when I save the file

the path should be /static/cloject.out/cloject/main.js instead of what's in the error message.

Could be related to https://github.com/adzerk-oss/boot-reload/issues/34

Did anyone notice that M-x . in cider on a boot project now takes you to point in the filesystem and not in the fileset like it used to?

So cool.

@micha: what's the best way to make an empty fileset?

do you have a fileset already?

you can do (assoc fs :tree {})

the purpose would be to start making tests for the builtin tasks

you really need to start with one that is already set up

cause of all the directories it needs

will boot core be loaded?

there is the boot.core/new-fileset function

but core needs to have been initialized

maybe the best way to drive the tests is with actual files on disk and the boot function

that would be the most realistic

i was just imagining that maybe it would be useful to be able to make a fileset in source code, to test little things like the sift flags

perhaps the tests could be in a boot task

then you can call core fns and stuff, and it will be all initialized correctly

that sounds good

if you never comit! the fileset then the directories aren't necessary