levand <luke.vanderh...@gmail.com> writes: > I use Emacs+Slime in windows (I'd prefer a Mac if I could afford one) > as my primary development environment. I start Emacs with a project- > specific batch file that adds all the libraries I use to the CLASSPATH > environment variable and then invokes Emacs, so all I have to do to > add a new library to the project is to dump it in the "lib" folder in > my project, and add a line in the bat file.
Rather than launching Emacs with a batch file that sets an environment var, it's probably better to set your classpath in elisp. That way you can take an existing Emacs instance and start using it for clojure dev without restarting it. Here's what I use for Mire: http://github.com/technomancy/mire/blob/30486954d36b8e55c6dad90bd8bd0bdeeaf32131/mire.el Since my app provides telnet access (it's a MUD), I also define an Emacs function to launch a telnet buffer to try things out. > Currently I am in an effort to put my existing code, except for the UI > portions, under complete test coverage using the test-is library. To > keep things clean, I am putting all the tests for each file in a > separate file. Making sure your library has automated tests is essential, but I find it's usually a lot of tedious work to add tests after your code is written. It's a much smoother workflow to write your tests first. This has the triple benefit of forcing you to think about the shape of your API up front, letting you know when your implementation is working correctly, and leaving you with a full regression suite when you're done at no extra effort. Of course you have to learn to test the right things and know what edge cases to watch for, but this comes with time. As you're starting out it's better to err on the side of comprehensiveness. Since you're already using SLIME, you might be interested in clojure-test-mode.el: http://github.com/technomancy/clojure-mode/blob/77a91fbcb352e23afe3f284aa6d2f9de4bb4f9a0/clojure-test-mode.el This allows you to get instant feedback from test runs within your buffer, highlighting failures in red and errors in brown. I've found it's streamlined my workflow immensely. It's still pretty new though, so be sure to let me know how it works for you if you try it out. > This is actually my first experience with unit tests. The motivator > for it is a problem I am still struggling with - my time spent > debugging is increasing exponentially relative to the amount of code I > have. Hopefully unit tests, in conjunction with writing smaller, more > atomic functions will allow me to have more confidence in individual > functions which will ease the debugging process. My approach in these situations is to start with a high-level test, and if this doesn't work, break it down into more and more specific tests until you find the specific function or situation that breaks. Of course, performing this effectively depends a lot on intuition in more complicated codebases, so it's definitely tricky to know what to test next when you're starting out. In my experience, debuggers are good for two things: investigating bugs in your infrastructure (in Clojure or other dependencies) and investigating performance problems. If you are feeling the need to step into a debugger to deal with correctness problems, it's merely a sign that your test suite is lacking in coverage. -Phil http://technomancy.us --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
