I was wondering what autotest tools exists for clojure. In Ruby I have ZenTest, redgreeen etc to continuously keep on testing my code. I would like to have something similar for Clojure
So far I have found this simple script https://github.com/devn/clojure-autotest on the github. A bit crude for my taste. All tests run when a change occurrs. Also it may blurt out a long stacktrace in case of syntax errors, obscuring what goes wrong.
Take a look at the Testing section on the Leiningen plugin page.
Notably there's lein-autotest for Stuart Sierras lazytest framework and speclj.
If you are using clojure.test there are a few options available. lein-test-refresh is what I use (I'm also the author). Other options include quickie and prism.
If you use expectations then there is lein-autoexpect. I'm also the author of that.
Midje has built in support for autotesting. I'm not sure what the options are for Speclj.
Related
I'm creating a library of components in Modelica, and would appreciate some input on techniques for unit testing the package.
So far I have a test package, consisting of a set of models, one per component. Each test model instantiates a component, and connects it to some very simple helper classes that provide the necessary inputs and outputs.
This works fine when using it interactively in the OMEditor, but I'm looking for a more automated solution with pass/fail criteria etc.
Should I start writing .mos scripts, or is there another/better way ?
Thanks.
I like how Openmodelica testing results look, see
https://test.openmodelica.org/libraries/MSL_3.2.1/BuildModelRecursive.html
click on a red cell: https://test.openmodelica.org/libraries/MSL_3.2.1/files/Modelica.Electrical.Analog.Examples.AD_DA_conversion.diff.html
choose "javascript" for a failing signal: https://test.openmodelica.org/libraries/MSL_3.2.1/files/Modelica.Electrical.Analog.Examples.AD_DA_conversion.diff.resistor.v.html
No idea how they are doing it, though. Obviously some kind of regression testing is done, with previous results stored, but no idea if that is from some testing library or self-made.
In general, I find it kinda sad/suboptimal, that there isn't "the one" testing solution everybody can/should use (cf. e.g. nose or pytest in the python ecosystem), instead everybody seems to cook up their own solutions (or tries to), and all you find is some Modelica conference papers (often without a trace of implementation) or unmaintained library of unknown status.
Off the top of my head, I found/know of (some already linked in other answers here)
OM testing
JModelica testing (seems to only test for compiler errors?)
Xogeny test (Some tests of the library itself fail for me. Also, does not seem to include a test runner)
MoUnit (something by Fraunhofer, and not publically available - maybe in OneWind/OneModelica?)
UnitTesting (apparently some kind of predecessor of XogenyTest. Also, no sources/implementation found)
Optimica Testing Toolkit (apparently a commercial product by Modelon)
SystemModeler VerificationTest
buildingspy Python package, for regression testing among other things. Under the umbrella of the Berkeley Modelica Buildings Library. (Simulation only with Dymola)
Modelica_Requirements library -- define requirements for simulation. (claimed to be open source and implemented, but apparently not available anywhere)
... I'm sure there are more I have forgotten or am not aware of
This seems like a pathological instance of https://xkcd.com/927/. It's kinda impossible for a (non-dev) user to know which of those to choose, which are actually good/usable/available/...
(Not real testing, but also relevant: parsing and semantic analysis using ANTLR: modelica.org/events/Conference2003/papers/h31_parser_Tiller.pdf)
Writing a .mos script would be one way but there is also a small proof-of-concept library by Michael Tiller: XogenyTest which you could use as a basis.
I prefer using the .mos script, it works pretty well when you further integrate your test framework into a continuous integration tool. BuildingPy is a good example of this, though it's not implemented in CI tools, it's still a good tool.
Here's a reference of a good framework design:
UnitTesting: A Library for Modelica Unit Testing
If you have Mathematica and SystemModeler you can run the simulation from Mathematica and use the VerificationTest "function" to test:
VerificationTest[Abs[WSMSimulate["HelloWorld"]["x", .1] - .90] < .01].
Multiple tests can then be simulated in a TestReport[].
I have been learning Clojure a bit recently. Is there such a thing in Clojure world as Scala-like worksheets, into which I can put any code and get it evaluated as soon as I save it? Or maybe there's a similar solution for Clojure?
I am now working with lein repl and, sadly, can't say it's the most usable tool ever.
In Lisp development in general (and Clojure in particular) the preferred programming style is what's usually dubbed interactive programming - the developer keeps an image of the app loaded at all times and interacts with it via a REPL. You can easily modify the loaded code on the fly and test changes immediately in the REPL (that's not easy at all with Scala - one has to resort to something like JRebel to do it). I find the Scala worksheets a pretty primitive solution in comparison...
The workflow that I follow in Clojure is:
I open nREPL.el in Emacs - this loads my lein2 project with all of its dependencies and gives me a REPL which I can use the try out stuff
I write some code in source code and load the changed functions (maybe by evaluating a top level form with C-M-x
Afterwards I'd press C-x C-z to jump back to the REPL and I try out the new code in it
I go back to step 2
Basically the Clojure REPL is much more powerful than the Scala REPL and I personally consider it hugely superior to the Scala IDE worksheets. Once you get used to the interactive incremental style of programming Lisp offers everything else starts to look strangely complex by comparison. I'm not familiar with Eclipse's CounterClockWise Clojure plugin, but I'm pretty sure it offers similar functionality to Emacs's nREPL.el.
You might want to take a look at the autoexpect plugin for Leiningen. Every time you save any file in the working directory, the plugin compiles and runs your code; as a bonus, it will evaluate any "expect" function calls which can serve as tests. This is very helpful for test driven development and is a nice compliment to working with the REPL as described in the other answer (I often use one or the other or both together depending on how many test cases I have in place).
I should note that running autoexpect is far faster than running "lein test" or "lein run" repeatedly, due to the startup cost of the JVM and Leiningen.
It sounds like what you are looking for is the Clojure Koan plugin. This a worksheet-style problem-solving exercise tool that watches your edits and provides instant feedback on the correctness of your work.
For actual development workflow I second the advice others here have provided on tooling and interactive environment setup, but since you specifically said you are learning Clojure, this can be a fun approach. There is also a web application called 4Clojure that you might have fun playing with.
However you will eventually (or right away) want to get a smooth and convenient development environment set up, and I haven't seen any mention so far of a few important tools. One person mentioned Nrepl. If you like Emacs, there's a slime/swank-like interaction mode that jacks into nrepl called nrepl.el that provides very nice integration between editing files and messing around in the repl. Similarly there is VimClojure, and you can find plugins for IntelliJ (LaClojure) and Eclipse (Counterclockwise) that are also popular and well-maintained.
Someone mentioned autoexpect. If you are looking for a good TDD setup, I would recommend midje. If you are using a 2.0 preview release of leiningen there are a few issues with the lazytest integration being in flux, and lazytest itself is or should be deprecated. But I prefer midje over expectations, personally, and these problems will surely be worked out in the 2.0 release of lein-midje. The stable version of lein-midje that works with the non-preview (1.x) leiningen has autotest-like functionality using lazytest.
As nobody has mentioned it, cursive is really nice these days, although I was sad to move back to a full blown IDE. You can easily do the same thing as Emacs with the built in repl, just move into the namespace that you are working with and synchronise every time you make changes. It's a really nice way of working.
Are there any good plugins for static code analysis for Eclipse CDT?
I found two so far:
Cppcheck plugin, but this still needs the original cppcheck executable
CppChecker, but this didn't work (it didn't do anything)
Are there any more that are better? Or how do I get CppChecker to do something (or is it a static code analyiser at all? the website is not clear at all)?
There is another called "Codan," stands for CODe ANalysis.
It can be reviewed at this wiki, with links to the tool:
http://wiki.eclipse.org/CDT/designs/StaticAnalysis
I cannot answer whether this is the better than your list, but at least it's another option you can review. Eclipse integration seems to be its only requirement.
Keep in mind that this is a work in progress, but given its goals, it may suit your short-term needs.
You can always run lint inside Eclipse as well. I wrote up a blog entry on doing it manually. However, there also exists Visual Lint and it works in VS and Eclipse. It's not perfect but it's easier than setting it all up manually.
I suggest a free plugin based on Codan framework called Artemis. You can get it from ecliplse marketplace. There are other checkers but only plugins integrated into Codan, like this one, can perform real-time analysis in Eclipse.
does anyone know of a good profiling tool or library for Clojure?
I would prefer something that could be used from the REPL, along the lines of (with-profiling ...) in Allegro Common Lisp back in the day.
Is there anything along those lines?
Or do you have any experience with (non-commercial) Java profilers that work well with Clojure?
I found VisualVM (see here and here) to be very convenient. Its use with Clojure has been described about a year ago in this blog post; as far as I can see, it's not outdated in any way.
Note that the GUI from which one starts the VisualVM profiler has a prominent text area where one can enter classes / packages to be excluded from profiling -- I find the results rather more useful when clojure.* is on that list.
There's a newish Clojure library which offers profiling: https://github.com/ptaoussanis/timbre
Just found profile in Clojure contrib.
It doesn't work for large amounts of code (it blew up with OutOfMemoryError on a Project Euler solution which VisualVM handled just fine) and it requires you to insert profiling calls in the functions you want to profile.
Still, it's a better alternative to VisualVM in the cases where you just want to profile a couple of functions.
Quick heads-up that I've deprecated Timbre's profiling for a new dedicated Clojure + ClojureScript profiling lib at https://github.com/ptaoussanis/tufte.
That's basically a refinement of the stuff from Timbre, plus dedicated docs.
The README includes a comparison with JVM tools like VisualVM, YourKit, etc.
I just recently started learning the Scala language and would like to do it in TDD-way. Could you share your experiences on the unit testing frameworks there are for Scala and the pros/cons of them.
I'm using IntelliJ IDEA for Scala development, so it would be nice to be able to run the tests with IDE-support.
Have you looked at ScalaTest ?
I've not used it, but it comes from Bill Venners and co at Artima, and consequently I suspect it'll do the job. It doesn't appear to have IDE integration, however.
This blog entry is a little old, but suggests that TestNG is the best option for testing Scala. TestNG will certainly have IDE integrations.
EDIT: I've just realised that I wrote this answer in 2009, and the world has moved on (!). I am currently using ScalaTest, the IDE integration works fine, and I can strongly recommend it. In particular the matcher DSL works very nicely
I'm the author of specs. If you're a Intellij user, I advise you to mix-in in the org.specs.runner.ScalaTest trait to your specification and run it as a ScalaTest suite.
If you have any issue with that, or anything else feel free to send a message to the specs-users mailing list.
You could also check out Specs it's fairly complete and IIRC is heavily used as part of Lift.