There’s quite a bit of extensibility in clojure.test. A variety of test runners and report formatters, such as James Reeves’ Eftest, Metosin’s boot-alt-test, and Paul Stadig’s Humane Test Output hook into the clojure.test reporting framework.
assert-expr, which allows
you to extend the
is macro to encapsulate domain-specific testing,
as well as add domain-specific reporting. Many of clojure.test’s own
assertions, such as
are implemented as
assert-expr methods. Daniel Solano Gómez has
written a library with helpers for Clojure spec called
tacular which includes a number of custom assertions. The
test.check library uses a custom assertion to improve
reporting in its
defspec testing macro.
Writing these custom assertions in a portable way can be a bit of a
trick, so let’s work through an example: an assertion that tests the
data returned from a thrown instance of
I’m working on an Om Next app with a Pedestal backend. Figwheel is a great way to do ClojureScript development, and the Reloaded workflow is really nice for working on Clojure servers. However, reloading Clojure code in the JVM still has corner cases which are difficult to solve. When you run into one, it’s not always obvious what’s causing the problem. Stuff just starts behaving weirdly. And I ran into just such a bug the other day.
I asked a good friend of mine to review my post on route naming in Pedestal. He’s not familiar with Clojure and said that he wanted to hear about how I chose Om and Pedestal. I had considered including a summary of these choices, but it felt out of place, detracting from the main point of how I worked through a development problem. While I don’t think my reasons for choosing these libraries are novel, I think they’re worth noting, so from the perspective of someone relatively new to web application development in Clojure, I’m noting them here.
Om Next remotes feature a single API endpoint that accepts both
POST request methods. The Om Next parser looks at the request
parameters—not the request method—to determine what action to take; only a
single handler calling the parser is needed. How do you define Pedestal routes
for the same endpoint with two request methods but only a single handler?
Just starting out using Pedestal, the solution wasn’t clear to me.
The web is not known for its fine typography and layout. There have been improvements over the years: widespread UTF-8 support makes character set problems less of an issue; post-processing tools make typographically correct punctuation easier to use; advances in CSS provide alternatives to table-based layout and made responsive design possible.
In the print world, tools such as LaTeX and
Adobe InDesign give you a great deal of control over features such
kerning, tracking, ligatures, hanging punctuation, orphans and widows,
hyphenation, and justification. CSS has limited support for some of these
OpenType features), but it doesn’t compare to the level of control afforded by
these other tools.
I inherited a PostgreSQL database that suffered from a lack of rigorous schema design. Column types were used and abused, such as Unix time values in varchar columns. Nullable columns for required data. Obscure naming conventions and magic integer values mixed with empty spaces and sometimes special text values, none of which were documented. Multiple comma-separated ints in text columns.
It is not easy to efficiently represent and access trees and other graph structures in relational databases, and this difficulty has motivated the popularity of graph database solutions such as Neo4J. That said, it’s not always practical to set up a dedicated graph database in addition to an existing SQL database instance.