I'm a newbie with Clojure and Counterclockwise and I succeeded adding a Leiningen 2 project with "Poor man's integration" (External tools, linked from question Using Clojure and Leiningen with IDEs).
My alternatives for running tests so far:
From command line : lein test
Running "lein test" with "Poor man's integration" (External tool)
These work pretty fine but I'm wondering whether there's some smoother alternative, for example showing the tests run like with JUnit etc?
Or with more general formulation, how to have fluent TDD flow with Counterclockwise?
Another alternative I found (with clojure.test API) was loading the test file in REPL (Alt+Cmd+S) and calling run-tests:
(run-tests)
With some trying, I can re-run the tests with my modifications by loading the modified file to REPL and calling run-tests again. (Works but isn't probably the final solution)
Midje with autotest in REPL seems to be worth checking out.
One way to do this is to use cljunit as an interface between the JUNit runner in Eclipse and your Clojure tests.
Related
It's Typesafe Activator 1.2.10 on Windows 7, Scala 2.11.4, sbt 0.13.7. All packages installed using .msi.
When I run activator ui I get error:
Error: Could not find or load main class ui
and nothing happens then.
It appears that you're facing permission-related problems.
I can't give you the exact steps to sort it out (as I'm on Mac OS), but you should be able to work it around by running cmd as Administrator and then executing activator ui again.
There's also the version 1.2.12 so you may have more success with it. You don't need separate installations of Scala and sbt, either, as activator is going to take care of them (that's one of the many reasons to use the tool after all).
I have a Play Project (using Scala) with a bunch of Selenium tests in a file.
I am using SBT as my build tool. In my SBT console, I run the tests file using:
sbt "test-only test.selenium.MySpec". I see that all the tests are running sequentially even though I have sbt.Keys.fork in Test set to true (it's the default, I believe).
I am using Firefox browser for my Selenium tests. I am on Selenium 2.42.0, Play 2.2.2, SBT 0.13.0 and Scala 2.10.4 if that matters.
Is it possible to run the tests in parallel (on my local machine) ? I have seen other options like Selenium Grid where I can distribute my tests by horizontal scaling, but I am trying to have this setup on my local machine.
Fork does not mean "run in parallel". Fork means "start a new JVM process to run the tests".
Sbt 0.13.5 has some new/experimental code to run forked tests in parallel. You can enable this via the following setting:
testForkedParallel in Test := true
try it out and let us know if you run into any issues. I expect we'll be investing more time into handling parallel log collection in the future, but for now what's there should be good enough for basic tests and development.
I have a working Clojure-1.4.0 / emacs24 / leiningen-2.0 tool chain working on Mac OSX 10.8. I got it going very quickly by following the instructions at the following URLs:
http://clojure.org/getting_started
https://github.com/technomancy/leiningen
http://clojure-doc.org/articles/tutorials/emacs.html
One way I check that it works is I go to a project directory and type
lein test
and it runs all the unit tests in my project directory. I can also do C-c , in clojure-mode in emacs, and it does the same thing. Great! Now the question: all this runs the clojure installation I have in ~/clojure-1.4.0, which I see by typing
lein repl
in a project directory. I have a new installation of clojure in ~/clojure-1.5.0 now, and I would like to make leiningen and emacs point to that new version. However, during the setup of leiningen and the emacs mode, I never manually told them where to find the clojure version. They found that magically and opaquely -- in fact, the whole process was very magic, and that was great at that time. I suppose I could tear everything down and build it up again from scratch, but that seems brute-forcedly inefficient. I could also hack-replace the files in the 1.4 directory with the files from the 1.5 directory. That might work one time, but it's so obviously wrong I really don't want to think about it. I need to do this the right way so that when the next version updates come along, I can keep the toolchain going as smoothly as possible.
I am just starting with all this, so I am far from mastery of any of these tools and I'll be grateful for noob-level advice on keeping it all going.
Just change clojure version in ./project.clj in your project directory:
:dependencies [... [org.clojure/clojure "1.5.0"] ...]
test:
$ lein repl
user=> *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier nil}
Edit:
They found that magically and opaquely
Default clojure version is built into lein's project.clj template which renders to your <name>/project.clj file when you do lein new <name>.
I'm running some tests for Django, and some other tests for the website using Selenium.
My choice of Testing framework is amazing Pytest.
for testing Django I've currently installed pytest-django plugin and tests for Django run as expected, however now I'm back to my previous tests that don't need Django plugin.
I start tests and the Django plugin is picked up automatically.
I've checked the documentation and found the article where it is explained how to disable\deactivate plugins, however when I run this command:
py.test -p no:django
I get an error that my "DJANGO_SETTINGS_MODULE" is not on sys.path.
Also
commands like:
py.test --traceconfig
or
py.test --version
throw me the same error.
Looks like Django plugin is getting to deep? Why is it called when I'm just checking the version or the 'installed plugins'?
QUESTION: Is there any way to temporary deactivate this plugin without uninstalling it?
This should work. When i install pytest-2.3.4 and run py.test -p no:django --version i don't get the DJANGO_SETTINGS issues. I get it when i leave away the -p no:django disabling.
If it doesn't work, please link to a full trace on a pastebin.
IIRC this is because of a combination of things:
On startup py.test looks for the setuptool entrypoint "pytest11"
Entrypoints get imported before they get activated or deactivated
pytest-django (as released, currently 1.4) does a load of Django imports upfront
A lot of Django needs the settings module configured even at import time
Unfortunately this is unavoidable in the released version of pytest-django. And the answer originally was: no, run the pytest-django and other tests in different virtualenvs.
However it is also the reason we started work on a version of the plugin which avoids these problems. What I consider the best version right now is the pytest23 branch at https://github.com/flub/pytest_django This version is pretty feature complete, certainly compared to the released version, it just needs a little more polishing mainly on the tests and documentation.
I believe/hope that within the next few weeks this branch will be merged and released, I just need to get Andreas to have a look through and agree. I consider it certainly stable enough to start using.
Does SBT make use of fsc?
For test purposes I am compiling a 500-line program on a fairly slow Ubuntu machine (Atom N270). Three successive compile times were 77s, 66s, and 66s.
I then compiled the file with fsc from the command line. Now my times were 80s, 25s, 18s. Better! That implies to me sbt is not using fsc. Am I right? If so, why doesn't it use it?
I may try getting sbt to explicitly use fsc to compile, though I am not sure I will figure out the config. Has anyone done this?
This discussion made me realize I have been using sbt the wrong way.
Instead of (from the command line):
$ sbt compile
$ sbt test
..one should keep sbt running and treat it as the command prompt.
$ sbt
> compile
...
> test
It has the command history and even ability to dive back into OS command line. I wrote this 'answer' for others like me (coming from a Makefile mindset) that might not realize we're taking the pill all wrong. :)
(It's still slow, though.)
SBT cannot benefit from the Fast Scala Compiler when you run it interactively (with or without using its continuous build mode) because the Scala compiler classes are loaded and get "warmed up" and JIT-ed, which is the entirety of fsc's advantage.
At least for SBT 0.7.x the authors explain that it is not as fast as fsc, which caches the compiler instance (including the loaded libraries), rather than just the JITted compiler classes:
http://code.google.com/p/simple-build-tool/wiki/ChangeDetectionAndTesting
My experience also confirms that fsc is faster for full compiles, but does not automatically select what to recompile.
For SBT 0.10, I can find no docs whatsoever on this issue.
You don't need to do it anymore. Sbt has its own way now:
https://github.com/sbt/sbt/wiki/Client-server-split