Giter Club home page Giter Club logo

doo's Introduction

doo

CircleCI Build status Clojars Project

A library and Leiningen plugin to run cljs.test in many JS environments. For Boot plugin, see boot-cljs-test.

...and I would have gotten away with it, too, if it wasn't for you meddling kids.

The latest stable release:

{:plugins [[lein-doo "0.1.11"]]}

To use doo you need to use [org.clojure/clojurescript "0.0-3308"] or newer.

Usage

Plugin

All arguments are optional provided there is a corresponding default under :doo in project.clj:

lein doo

lein doo {js-env}

lein doo {js-env} {build-id}

lein doo {js-env} {build-id} {watch-mode}
  • js-env can be any chrome, chrome-headless, firefox,firefox-headless, ie, safari,opera, slimer, phantom, node, rhino, nashorn, lumo, or planck. In the future it is planned to support v8, jscore, and others.
    • Note that chrome-headless requires karma-chrome-launcher >= 2.0.0 and Chrome >= 59
    • Note that firefox-headless requires karma-firefox-launcher >= 1.1.0 and Firefox >= 56
  • watch-mode (optional): either auto (default) or once which exits with 0 if the tests were successful and 1 if they failed.
  • build-id is one of your cljsbuild profiles. For example test from:
:cljsbuild
  {:builds [{:id "test"
             :source-paths ["src" "test"]
             :compiler {:output-to "resources/public/js/testable.js"
                        :main your-project.runner
                        :optimizations :none}}]}

Notice that :main is set to the namespace your-project.runner where you define which test namespaces you want to run, using:

(ns your-project.runner
    (:require [doo.runner :refer-macros [doo-tests]]
              [your-project.core-test]
              [your-project.util-test]))

(doo-tests 'your-project.core-test
           'your-project.util-test)

doo.runner/doo-tests works just like cljs.test/run-tests but it places hooks around the tests to know when to start them and finish them. Since it is a macro that will be calling said namespaces, you need to require them in your-project.runner even if you don't call any of their functions. You can also call (doo.runner/doo-all-tests) which wraps cljs.test/run-all-tests to run tests in all loaded namespaces. Notice that doo-tests needs to be called in the top level and can't be called inside a function (unless you explicitly call that function in the top level).

Then you can run:

lein doo slimer test

which starts an ClojureScript autobuilder for the test profile and runs slimerjs on it when it's done.

You can also call doo without a build-id (as in lein doo phantom) as long as you specify a Default Build in your project.clj.

Boot

doo is packaged as a Boot task in boot-cljs-test.

Library

To run a JavaScript file in your preferred runner you can directly call doo.core/run-script from Clojure:

(require '[doo.core :as doo])

(let [doo-opts {:paths {:karma "karma"}}
      compiler-opts {:output-to "out/testable.js"
                     :optimizations :none}]
  (doo/run-script :phantom compiler-opts doo-opts))

You can run doo.core/run-script with the following arguments:

(run-script js-env compiler-opts)
(run-script js-env compiler-opts opts)

where:

  • js-env - any of :phantom, :slimer, :node, :rhino, :nashorn, :lumo, :planck, :chrome, :chrome-headless, :firefox, :firefox-headless,:ie, :safari, or :opera
  • compiler-opts - the options passed to the ClojureScript when it compiled the script that doo should run
  • opts - a map that can contain: :verbose - bool (default true) that determines if the scripts output should be printed and returned (verbose true) or only returned (verbose false). :debug - bool (default false) to log to standard-out internal events to aid debugging :paths - a map from runners (keywords) to string commands for bash. :exec-dir - a directory path (file) from where runner should be executed. Defaults to nil which resolves to the current dir

Setting up Environments

This is the hardest part and doo doesn't do it for you (yet?). Right now if you want to run slimer, phantom, node or nashorn that ships with the JDK 8, you need to install them so that these commands work on the command line:

phantomjs -v

slimerjs -v

node -v

jjs -h

rhino -help

lumo -h

planck -h

If you want to use a different command to run a certain runner, see Paths.

Remember that Rhino and Node don't come with a DOM so you can't call the window or document objects. They are meant to test functions and logic, not rendering.

Slimer & Phantom

If you want to run both, use lein doo headless {build-id} {watch-mode}.

Do not install Slimer with homebrew unless you know what you are doing. There are reports of it not working with ClojureScript when installed that way because of dated versions.

Note: Slimer does not currently throw error exit codes when encountering an error, which makes them unsuitable for CI testing.

Node

Some requirements:

  • Minimum node version required: 0.12
  • :output-dir is needed whenever you are using :none.
  • :target :nodejs is always needed.
:node-test {:source-paths ["src" "test"]
            :compiler {:output-to "target/testable.js"
                       :output-dir "target"
                       :main example.runner
                       :target :nodejs}}

Karma

Installation

Karma is a comprehensive JavaScript test runner. It uses plugins to extend functionality. We are interested in several "launcher" plugins which start a browser on command. You might want any of:

- karma-chrome-launcher
- karma-firefox-launcher
- karma-safari-launcher
- karma-opera-launcher
- karma-ie-launcher

Alternatively, if you don't want doo to launch the browsers for you, you can always launch them yourself and navigate to http://localhost:9876

We also need to properly report cljs.test results inside Karma. We'll need a "framework" plugin:

- karma-cljs-test

Karma and its plugins are installed with npm. It is recommended that you install Karma and it's plugins locally in the projects directory with npm install karma --save-dev. It is possible to install Karma and its plugins globally with npm install -g karma, but this is not recommended. It is not possible to run mix local and global Karma and Karma plugins.

Karma provides a CLI tool to make running Karma simpler and to ease cross platform compatibility. doo uses the CLI tool as the default runner, if you don't install it you will need to configure doo.

For local installation run:

npm install karma karma-cljs-test --save-dev

and install the Karma CLI tool globally with

npm install -g karma-cli

then install any of the launchers you'll use:

npm install karma-chrome-launcher karma-firefox-launcher --save-dev
npm install karma-safari-launcher karma-opera-launcher --save-dev
npm install karma-ie-launcher --save-dev

The --save-dev option informs npm that you only need the packages during development and not when packaging artifacts.

The installation will generate a node-modules folder with all the installed modules. It is recommended to add node-modules to your .gitignore.

If you are using lein-npm, follow their instructions.

Measuring coverage with Istanbul

It's possible to generate Istanbul coverage reports for JS files produced from CLJS.

To make it work two things are required.

Install your karma coverage plugin.

npm install karma-coverage --save-dev

Add coverage seetings to your project.clj

:doo {:coverage {:packages [my-app.module]
                 :reporter {:check {:global {:statements 100}}}}}

Packages section is essential, it enables coverage cofiguration and defines which files would have coverage instrumentation.

By default HTML reporter is enabled which creates coverage folder with the report and there are no coverage reqirements.

Anything under :reporter is passed as coverageReporter config to Karma config.

See Karma coverage for more details. See Reagent covered for a sample project configuration.

Non-standard Karma configuration

If you are using a local installation and/or node_modules is not located at the project root, you need to tell doo about it. Add this to your project.clj:

:doo {:paths {:karma "path/to/node_modules/karma/bin/karma"}}

:cljsbuild { your-builds }

and make sure that the file karma/bin/karma exists inside node_modules. If your package.json and node_modules folder are in the same directory than your project.clj, then you should use:

:doo {:paths {:karma "./node_modules/karma/bin/karma"}}

:cljsbuild { your-builds }

For more info on :paths see Paths.

Global installation will allow you to use karma in all of your projects. The problem is that it won't be explicitly configured in your project that karma is used for testing, which makes it harder for new contributors to setup.

In some systems (e.g. Ubuntu) you might need to run all npm commands as root: sudo npm install karma --save-dev

Karma Phantom and Karma Slimer (experimental)

To avoid starting a new Slimer/Phantom on every run while using auto, we can use Slimer/Phantom through Karma.

Install any of the launchers you'll use:

npm install karma-phantomjs-launcher --save-dev
npm install karma-slimerjs-launcher --save-dev

and call

lein doo karma-phantom test auto
lein doo karma-slimer test auto

If you are using once, the regular phantom/slimer runners are recommended.

Note: karma-slimer sometimes fails to close the running Slimer instance, which you need to close manually.

Electron (experimental)

After installing Electron install the launcher with

npm install karma-electron-launcher --save-dev

and call

lein doo electron test

Planck

Planck 2.14.0 or later is required.

Paths

You might want to use a different version of node, or the global version of Karma, or any other binary to run your tests for a given environment. You can configure that paths like so:

:doo {:paths {:node "user/local/bin/node12"
              :karma "./frontend/node_modules/karma/bin/karma"}

:cljsbuild { your-builds }

Paths can also be used to pass command line arguments to the runners:

:doo {:paths {:phantom "phantomjs --web-security=false"
              :slimer "slimerjs --ignore-ssl-errors=true"
              :karma "karma --port=9881 --no-colors"
              :rhino "rhino -strict"
              :node "node --trace-gc --trace-gc-verbose"}}

Aliases

You might want to group runners and call them from the command line. For example, while developing you might only be interested in chrome and firefox, but you also want to test with safari before doing a deploy:

:doo {:alias {:browsers [:chrome :firefox]
              :all [:browsers :safari]}}

:cljsbuild { my-builds }

Then you can use:

lein doo browsers my-build  # runs chrome and firefox

lein doo all my-build # runs chrome, firefox, and safari

As you can see, aliases can be recursively defined: watch for circular dependencies or doo will bark.

The only built-in alias is :headless [:phantom :slimer].

Default Build

To save you one command line argument, lein-doo lets you specify a default build in your project.clj:

:doo {:build "some-build-id"
      :paths { ... }
      :alias { ... }}

:cljsbuild
  {:builds [{:id "some-build-id"
             :source-paths ["src" "test"]
             :compiler {:output-to "out/testable.js"
                        :optimizations :none
                        :main example.runner}}]}

Custom Karma configuration

You can supply arbitrary configuration options to Karma under the :karma {:config {}} key. For example, if you want to use karma-junit-reporter, do this:

{:doo {:karma
       {:config {"plugins" ["karma-junit-reporter"]
                 "reporters" ["progress" "junit"]
                 "junitReporter" {"outputDir" "test-results"}}}}}

The options are merged to Doo's Karma configuration. By default, array values are merged by appending. For example, in the example above, the value of "plugins" is appended to the list of plugins needed by Doo. Merging is implemented with meta-merge, so if you need more control, you can use ^:replace and ^:prepend metadata.

Custom Karma launchers

To add custom Karma launchers (eg. as described in the Chrome Karma Plugin) you can add the following config entries to your project.clj as shown in the example below:

The plugin in the :launchers map should match an installed Karma plugin and the name should match a Karma launcher (possibly a custom one as shown in the following example). If needed, add "customLaunchers" configuration under the :config key.

You will then be able to run lein doo chrome-no-security from the comand line.

:doo {:karma
      {:launchers {:chrome-no-security {:plugin "karma-chrome-launcher"
                                        :name "Chrome_no_security"}}
       :config {"customLaunchers"
                {"Chrome_no_security" {"base" "Chrome"
                                       "flags" ["--disable-web-security"]}}}}

Travis CI

To run on travis there is a sample .travis.yml file in the example project: example/.travis.yml

(Currently only tested with PhantomJS.)

Developing

To run the tests for doo, you need to have installed rhino, phantomjs, slimer, chrome, node, and firefox. You will also need to run npm install in the library directory.

License

This project started as a repackaging of cemerick/clojurescript.test, therefore much of the credit goes to Chas Emerick and contributors to that project.

Copyright © 2016-2018 Sebastian Bensusan and Contributors.

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.

doo's People

Contributors

alun avatar amacdougall avatar arichiardi avatar bbbates avatar bensu avatar conan avatar crisptrutski avatar danielcompton avatar empperi avatar immoh avatar korkeala avatar matthewdarling avatar mfikes avatar miikka avatar mikesperber avatar moea avatar nberger avatar nwjsmith avatar projectfrank avatar vikeri avatar vloothuis avatar volrath avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

doo's Issues

Support custom command path / unoptimized test builds

Having some trouble using 0.1.6 with unoptimised CLJS builds - and the issue seems to be http://dev.clojure.org/jira/browse/CLJS-1444.

Until that is sorted out, such builds would need to be run from the :output-to directory.

Although this has its own problems, e.g. for commands only installed locally for the project, I can't think of another solution. On the flip-side this has advantages too (ie. support for non-global commands outside the project)

Make :main compatible with Figwheel

There are three ways to specify :main:

  1. :main 'app.core
  2. :main app.core
  3. :main "app.core"

We should support all of them. As noticed by @teaforthecat we currently don't support 2. which is Figwheel's preferred method.

  1. Is important since it is used in scripts for the compiler, and beginners will probably paste those to project.clj.

[Windows] ERROR: doo was not loaded from the compiled script

I checked out and ran the example like this:

git clone [email protected]:bensu/doo
cd doo/example
lein doo phantom test

I got this error:

ERROR: doo was not loaded from the compiled script.

Make sure you start your tests using doo-tests or doo-all-tests
and that you include that file in your build

I get this error in exactly the same way on my own project trying to get doo running, which is why I thought I'd give the example a try. Is there something I can do to resolve this?

I'm on Windows 10 using Git Bash.

Making lein-cljsbuild optional

Would you be open to supporting non lein-cljsbuild workflows that use :doo or :cljsbuild in project.clj? Considering that cljs.test comes with clojurescript, this library could be a go to for the bare metal workflow dnolen is encouraging with mies. Depending on if we use :doo or :cljsbuild, we would have to detect the presence of lein-cljsbuild. As for reimplementing cljsbuild fns, config seems trivial to implement if we assume the latest builds format. subproject is a little involved but not much inlining.
I'm happy to take a stab if desired

Usage via boot-cljs-test broken during changes to add Karma

Haven't tried to understand the error yet, or looked at your changes, but have verified that still working after #13 and broken on master.

Here's the stracktrace:

             clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: No value supplied for key: null
    data
java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: No value supplied for key: null
     java.lang.IllegalArgumentException: No value supplied for key: null
                                         ...
                       clojure.core/hash-map            core.clj:  371
                                         ...
                          clojure.core/apply            core.clj:  630
               clojure.java.shell/parse-args           shell.clj:   50
                       clojure.java.shell/sh           shell.clj:  112
                                         ...
                          clojure.core/apply            core.clj:  630
                         doo.core/run-script            core.clj:  150

Am just calling doo like so: (doo.core/run-script :rhino) "/super/long/boot/temp/path.js"

Cleanup node options

Currently node is very restricted to a small set of options. Cleaning up the runner script can remove most of those limitations.

lein doo only adds and downloads dependencies at test time

CI environments like CircleCI cache m2 dependencies to speed up build time and decrease load on third party Maven repos (like Clojars). They will typically do the following:

  1. Fetch all dependencies
  2. Cache the dependencies
  3. Run the tests

When using doo, it adds more dependencies to the project at test time, after the dependencies have been cached. There are a few possible options here to avoid this:

  1. Create some kind of command like lein doo deps which would run the project with the doo deps added, triggering leiningen to download the missing dependencies
  2. Add [doo "0.1.5-SNAPSHOT"] to the project dependencies to make sure the deps are included. I'm not familiar enough with doo to know if that is going to cause other problems
  3. Make lein deps download the doo dynamic dependencies as well. I really don't know if this is possible or not.

2 seems like the good short term option. It would also be good to document this limitation so others know how to work around it.

Running the tests exactly once?

First off, thanks a lot for doo; it's a fantastic tool :) While it works really well for development (since it watches and automatically runs the build), is there a way to get it to just run once, i.e. for CI?

Integration Tests?

Would it be at all possible for doo to make client-server integration testing more convenient, or is that out of scope?

It looks like the way to do it in lein is to have an alias where you spin up a ring server, run your tests, and spin the ring server back down:
https://groups.google.com/d/msg/clojurescript/rArkEBCRods/Bqo4IE5ehNUJ

Anyhow this is a marvelous library and I am looking forward to using it in all of my ClojureScript projects!

Pass arguments to runners

I wasn't able to find a way how to pass additional arguments to existings runners. For example if we specify :doo {paths {:phantom "phantomjs --web-security=false" }}} it will fail because doo will check if executable exists first and with additional arguments it will fail to do so.

One way could be adding additional arguments to doo settings or maybe it would be a better just to rely on karma and give user a way to specify a custom karma.config.js, so it will be possible to configure a lot of things there.

Currently I'm using the following workaround:
project.clj

:doo {:paths {:phantom "tests/phantom.sh"}}

tests/phantom.sh

#!/bin/bash
phantomjs --web-security=false --local-to-remote-url-access=true --ignore-ssl-errors=true $@

Add CI testing for doo

It would be good to have CI to run tests against doo to prevent regressions. One way to approach it would be to run tests which are multiple projects * all optimisations * all runners * Windows and Linux. Travis has a good test matrix capability to support this.

Clashes with React?

I was a bit desperate, not finding much information about how to run tests with cljs.test. So I used the friendly cemerick.cljs.test until I came across your plugin and was quite happy. However, a setup very similar to my cemerick.cljs.test setup before gives me this error:

;; ======================================================================
;; Testing with Slimer:
Warning: Error unmounting:
Error: Invariant Violation: unmountComponentAtNode(...): Target container is not a DOM element.
[JavaScript Error: "Error: Invariant Violation: _registerComponent(...):
Target container is not a DOM element." {file: "…/resources/public/js/test/test-main.js" line: 20314}

It seems like there's some problem with React, even though the one test I have now uses only plain clojure.core functions.

As I said, testing with cemerick.cljs.test worked. And I could run the tests directly in my application with run-tests, which rules out incompatibilities between cljs.test and cemerick.cljs.test as the cause.

The relevant section of project.clj looks like this:

:cljsbuild
{:builds
 [{:id "test"
    :source-paths ["src/cljs" "test/cljs"]
    :compiler {:output-to "resources/public/js/test/test-main.js"
               :output-dir "resources/public/js/test"
               :main 'theatralia.t-runner
               :optimizations :whitespace}]}

Can you help?

Add explicit "runner not installed" errors

As you demonstrate in https://github.com/bensu/doo#setting-up-environments, there are simple checks to test whether underlying runners are installed.

For a user-friendlier experience, perhaps these exact checks should be performed by the application, so that friendlier error messages (or even installation instructions) can be shown.

Motivation for this comes from when a default runner is bundled downstream (eg. from a lein template martinklepsch/tenzing#28), and the end user may not be familiar with what the command means.

Source maps for stack traces?

Is it possible to get stack traces for errors from Karma?

At the moment they look like this:

Chrome 46.0.2490 (Mac OS X 10.11.0) bigco.base.util-test fail FAILED
    Fail (fail) (cljs/test.js:417:14)
    Expected (= 1 2)
    Actual: (not (= 1 2))

I'm not sure if this is related or not, but when I open the Karma Debug page, I get a bunch of warnings in the doo terminal about 404 for source map files, e.g.:

19 10 2015 08:24:30.989:WARN [web-server]: 404: /base/out/cljs_time/format.js.map

Support :none compilation with Rhino

Perhaps my googling was just weak, but was unable to find a good shim to use Rhino with {:optimizations :none, :main 'some.ns} style builds, or to alter the builds to "just work" with Rhino.

Came up with a very hacky modification (paste at the top) to the runner script to get this working:

global = this;

this.console = {log: print};

var base = new java.io.File(arguments[0]).getParent();

this.document = {};

this.document.getElementsByTagName = function () {
  return [{src: (base + '/output.out/goog/base.js')}];
}

this.document.write = function (source) {
  var src = source.match(/^<script src="([^"]+)"/)
  if (src) {
    var src = src[1];
    if ('/' !== src[0]) src = base + '/' + src;
    load(src);
  } else {
    var code = source.substring(8, source.length - 9);
    eval(code);
  }
};

this.CLOSURE_IMPORT_SCRIPT = function(src) { load(src); };

Note that {:output-dir ...} from the CLJS compilation options is used (know you were interested in possible uses for other params).

... obviously hope there is a better way however!

Browser test runner(s)

Interested in adding this? Thinking a QUnit style "refresh and read it" to start with, but this could be extended to drive Karma or a custom reporter to gather those stats back in the console.

Fix failing tests

This is a placeholder to fix the failing tests

lein test test.doo.core

lein test :only test.doo.core/integration

FAIL in (integration) (core.clj:101)
We can compile a cljs project
expected: (let [compiler-opts' (merge compiler-opts {})] (cljs/build srcs compiler-opts') (->> [:phantom :chrome :firefox] (mapv (fn [env] (-> env (doo/run-script compiler-opts' doo-opts) doo-ok?))) (every? true?)))
  actual: false

lein test :only test.doo.core/integration

FAIL in (integration) (core.clj:101)
We can compile a cljs project
expected: (let [compiler-opts' (merge compiler-opts {:optimizations :whitespace})] (cljs/build srcs compiler-opts') (->> [:rhino :phantom :chrome :firefox] (mapv (fn [env] (-> env (doo/run-script compiler-opts' doo-opts) doo-ok?))) (every? true?)))
  actual: false

lein test :only test.doo.core/integration

FAIL in (integration) (core.clj:101)
We can compile a cljs project
expected: (let [compiler-opts' (merge compiler-opts {:optimizations :advanced})] (cljs/build srcs compiler-opts') (->> [:phantom :rhino :chrome :firefox] (mapv (fn [env] (-> env (doo/run-script compiler-opts' doo-opts) doo-ok?))) (every? true?)))
  actual: false

Ran 5 tests containing 57 assertions.
3 failures, 0 errors.

Tests failed. cd library && lein test returned exit code 1

"Unable to resolve symbol: update in this context, compiling:(leiningen/doo.clj:99:35)"

hi!

this is my first time opening a github issue, please excuse me if i'm doing any of this wrong.

my build on travis-ci just started failing with the message in this issue's subject line. full traceback at https://s3.amazonaws.com/archive.travis-ci.org/jobs/82362310/log.txt . i'm unable to reproduce this locally, but that's probably because i'm not doing a good enough job of blowing away my currently downloaded libraries or something, i imagine that travis is running the most recent version of doo while i'm running an older version.

i see the string "(update" occur in 9c60f64 , and this just started happening for me, so i'm betting that this behavior was introduced in that commit.

i wish i could give you easy repro steps - is this not happening on your machine?

thanks!

Only :as and :refer options supported in :require / :require-macros;

clojure.lang.ExceptionInfo: Only :as and :refer options supported in :require / :require-macros; offending spec: [doo.runner :refer-marcos [doo-all-tests doo-tests]] at line 2 test/graphql-tlc/runner.cljs {:file #object[java.io.File 0x2ca93dee "test/graphql-tlc/runner.cljs"], :line 2, :column 1, :tag :cljs/analysis-error}

My runner looks like so:

Jonathans-MacBook-Pro:graphql-type-lang-compiler jonathan$ cat test/graphql-tlc/runner.cljs 

(ns graphql-tlc.runner
  (:require [cljs.test :as test]
            [doo.runner :refer-marcos [doo-all-tests doo-tests]]
            [graphql-tlc.test.core]))

(doo-tests 'graphql-tlc.test.core)

Don't close browser when tests finish

Is it possible to leave the browser up while running Karma tests? It would be really nice to not have the Chrome browser popping up and down when tests are auto running.

Add a default build

Since there is usually one test build per project, users should be able to call it with:

lein doo phantom

as long as they define it under :doo :default.

No namespace doo.runner error

Hello @bensu and again thanks for this refactoring!
First of all, my conf:

:plugins [[lein-cljsbuild "1.1.0"]
              [lein-figwheel "0.4.1" :exclusions [cider/cider-nrepl]]
              [lein-doo "0.1.6-SNAPSHOT"]]

  :clean-targets ^{:protect false} ["resources/public/js/compiled" "target" "out"]
  :hooks [leiningen.cljsbuild]
  :source-paths ["src/clj"]

  :cljsbuild {:builds [{:id "dev"
                        :source-paths ["src/cljs" "test/cljs"]
                        :figwheel {:on-jsload "launcher.test/run"
                                   :css-dirs ["resources/public/styles"]}
                        :compiler {:main "cljs-browser-repl.core"  ;; https://github.com/bensu/doo/wiki/Working-with-Figwheel
                                   :output-to "resources/public/js/compiled/cljs-browser-repl.js"
                                   :output-dir "resources/public/js/compiled/out"
                                   :asset-path "js/compiled/out"
                                   :optimizations :none
                                   :source-map-timestamp true}}
                       {:id "test"
                        :source-paths ["src/cljs" "test/cljs"]
                        :compiler {:main launcher.runner
                                   :output-to "resources/private/test/compiled/cljs-browser-repl.js"
                                   :pretty-print false}}
...

When I launch lein figwheel dev I receive a big:

Caused by: clojure.lang.ExceptionInfo: No such namespace: doo.runner, could not locate doo/runner.cljs, doo/runner.cljc, or Closure namespace "doo.runner"
 at clojure.core$ex_info.invoke (core.clj:4593)

clojure.lang.ExceptionInfo: No such namespace: doo.runner, could not locate doo/runner.cljs, doo/runner.cljc, or Closure namespace "doo.runner" {:tag :cljs/analysis-error}
    at clojure.core$ex_info.invoke(core.clj:4593)
    at cljs.analyzer$error.invoke(analyzer.cljc:562)
    at cljs.analyzer$error.invoke(analyzer.cljc:560)
    at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1668)
    at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2504)
    at cljs.analyzer$analyze_STAR_$fn__2094.invoke(analyzer.cljc:2585)
    at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)
    at clojure.core$reduce.invoke(core.clj:6518)
    at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2585)
    at cljs.analyzer$analyze.invoke(analyzer.cljc:2600)
    at cljs.analyzer$analyze_file$fn__2145.invoke(analyzer.cljc:2844)
    at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2839)
    at figwheel_sidecar.repl$analyze_build.invoke(repl.clj:242)
    at figwheel_sidecar.repl$analyze_builds.invoke(repl.clj:247)
    at figwheel_sidecar.repl$run_autobuilder_helper.invoke(repl.clj:295)
    at figwheel_sidecar.repl$start_autobuild.invoke(repl.clj:366)
    at figwheel_sidecar.repl$run_autobuilder.invoke(repl.clj:576)
    at user$eval12982.invoke(form-init8065958100227564854.clj:1)
    at clojure.lang.Compiler.eval(Compiler.java:6782)
    at clojure.lang.Compiler.eval(Compiler.java:6772)
    at clojure.lang.Compiler.load(Compiler.java:7227)
    at clojure.lang.Compiler.loadFile(Compiler.java:7165)
    at clojure.main$load_script.invoke(main.clj:275)
    at clojure.main$init_opt.invoke(main.clj:280)
    at clojure.main$initialize.invoke(main.clj:308)
    at clojure.main$null_opt.invoke(main.clj:343)
    at clojure.main$main.doInvoke(main.clj:421)
    at clojure.lang.RestFn.invoke(RestFn.java:421)
    at clojure.lang.Var.invoke(Var.java:383)
    at clojure.lang.AFn.applyToHelper(AFn.java:156)
    at clojure.lang.Var.applyTo(Var.java:700)
    at clojure.main.main(main.java:37)

Any workaround?

Share code between runners

It would make it easier to extend them, for example by improving the error messages on what namespaces were properly loaded.

No output from slimerjs runner

Despite the workaround for https://github.com/laurentj/slimerjs/issues/223 of using window.callPhantom, I'm not seeing any test results for the slimer option.

Have tried this with two projects, and in both cases only the slimer option is silent.

Any ideas?

Cannot require macros from test directory?

I have a then.clj file in the test/project directory (as opposed to src/project), but when I require it I get

java.io.FileNotFoundException: Could not locate project/then__init.class or project/then.clj on classpath.

I know the test directory is getting included in the build because it finds the .cljs files. Is there something special I need to do to get .clj files outside src to be found by the ClojureScript compiler?

Add support for JUnit test reporting

It would be nice to have JUnit test reporting as this is the lingua franca of test result reporting. This can then be used in a number of CI tools for more detailed test reporting, beyond just pass/fail.

Something like https://github.com/karma-runner/karma-junit-reporter could be good for test reporting, although it only supports Karma. Perhaps it would be better to create a reporter that can be used for any testing tool, relying on cljs.test report to get details.

Cut a new release?

There have been quite a few changes since the last SNAPSHOT release. Would it be possible to release a new version?

An issue with having long running snapshots is that when code changes in a SNAPSHOT it can break running tests. Normally you would deal with that by pinning to specific snapshot versions, like 0.1.5-20150918.... However I don't think it is possible (it's certainly not easy), to pin a particular lein-doo plugin SNAPSHOT and make it use a particular pinned version of the doo library it depends on, as lein-doo just specifies a dependency on 0.1.6-SNAPSHOT.

Would it make more sense to release alpha or beta versions when you don't want to release full versions?

Release 0.1.5

@bensu would it be possible to release 0.1.5? I understand that it's under a SNAPSHOT because the behaviour is subject to change, but it does raise the risk of breaking existing code, e.g. #36. The Karma test runner could still be marked as experimental and subject to breaking changes, but at least it would be a stable point for those that need to use it.

I know that I can specify a particular SNAPSHOT version to pin dependencies, but I don't know how widely spread this knowledge is and if others are doing it too.

Just a thought.

Run set of explicit tests only

It would be convenient to be able to run only specific tests, rather than whole namespaces. This would be particularly useful with downstream tooling eg. rerunning failing tests first on save, or only the tests that call the given function.

Expect the method would take vars, ie. (doo-test-vars #'ns/test-1 #'ns/test-2), as I don't believe something like resolve exists in Clojurescript.

Provide the ability to add arbitrary Karma plugins

I'd like to be able to add karma-junit-reporter to my karma.conf.js file. I can imagine in the long run that lots of people will all want to install their own Karma plugins. There are a few ways to accomodate this:

  • Add a command to allow people to generate a karma.conf.js file to disk and then they can add their plugins, configuration, e.t.c. to that static file. The problem with this approach is regenerating it when things change, and it getting out of date.
  • Allow extra arguments to be passed on the command line. Some Karma plugins can be activated by this method, though they probably still need some config provided
  • Allow people to provide extra config which gets merged into the map used for creating karma.conf.js. This would be somewhat similar to how Leiningen merges profiles into the main project config.

This presupposes that the Karma plugins will be able to understand the output of doo tests, I'm not sure if that's the case.

Relates to #34.

Error trying to use rhino

Hi,

I'm trying to use rhino with doo 0.1.6-SNAPSHOT. I installed nodejs and karma but when running lein doo rhino test I get the following output:

ERROR: doo was not loaded from the compiled script.

Make sure you start your tests using doo-tests or doo-all-tests
and that you include that file in your build

;; ======================================================================
;; Testing with :

Though, I do include and use (doo-tests 'foo.runner).

Any idea on what I am doing wrong?

Expose the running runner?

Hi @bensu,

I wanted to ask you if there is a way to know which runner is currently executed in order to pass it to my tests. For instance to execute node-specific configuration as test fixture.

If this is not exposed, I could work on doing it and submit a PR ;)

Feature request: add a way to inject javascript references

When running tests on doo, it'd be ideal to have a way to inject some Javascript libraries. For instance, Jayq expects you to have linked to the jQuery library from your page, so we'd need to inject it into the tests.

I'm using phantom, but expect this is something desirable for others as well.

Changing macro requires restarting process and triggering reload

I have several macros used by tests, and any time I change one of them, I have to stop the lein doo process and restart it, then (usually) touch my test file so doo recompiles the JS and runs the updated code. If I don't touch the test file, doo seems to use the original macro definition instead of the updated one.

clojurescript 1.7 vswap! failure

Hi @bensu. When I try to use this with a project generated from lein new mies using clojurescript 1.7.48 I get the following error:

$ lein doo phantom test once                                                                                                                            WARNING: Use of undeclared Var cljs.core/vswap! at line 5 test/reagent_raw/runner.cljs
;; ======================================================================
;; Testing with Phantom:
Hello world!

Testing reagent-raw.core-test
TypeError: undefined is not an object (evaluating 'cljs.core.vswap_BANG_.call')

  /var/folders/k6/nmwrydfd25l3zxq7f0rjsc_r0000gn/T/phantom3186709797736901614.js:34 in onError

Subprocess failed

I'm just doing a basic cljs test and using a runner as given in the readme. This failure also occurs with slimer. If I change to clojurescript "0.0-3308", I have no issue. My project.clj looks like this:

(defproject reagent-raw "0.1.0-SNAPSHOT"
  :description "FIXME: write this!"
  :url "http://example.com/FIXME"
  :dependencies [[org.clojure/clojure "1.7.0"]
                 [org.clojure/clojurescript "1.7.48" :classifier "aot"
                  :exclusion [org.clojure/data.json]]
                 [org.clojure/data.json "0.2.6" :classifier "aot"]]
  :jvm-opts ^:replace ["-Xmx1g" "-server"]
  :plugins [[lein-npm "0.6.1"]
            [lein-cljsbuild "1.0.5"]
            [lein-doo "0.1.4-SNAPSHOT"]]
  :npm {:dependencies [[source-map-support "0.3.2"]]}
  :cljsbuild {:builds
              [{:id "test"
                :source-paths ["src" "test"]
                :compiler {:output-to "out/testable.js"
                           :main 'reagent-raw.runner
                           :optimizations :none}}]}
  :source-paths ["src" "target/classes"]
  :clean-targets ["out" "release"]

  :target-path "target")

Let me know if I can provide anything more to recreate. I'd love to get this working on latest clojurescript. Thanks for providing a library that keeps us from copying and pasting cljs.test runners

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.