This is a very specific "coverage" tool which I think lots of Clojure libraries
could benefit from. https://github.com/ztellman/collection-check
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups
On Feb 4, 2014, at 11:20 AM, Aaron France wrote:
>> If you thoroughly test all your code when you write it why do you need a
>> tool to tell you you missed something?
>
> This is just so brain-dead stupid.
>
> How do you *know* that you thoroughly tested your code? Where do you
> get these me
On Tue, Feb 04, 2014 at 07:01:31AM -0800, Colin Yates wrote:
> I said that coverage tools answer a specific question; 'how much of my code
> is executed when I do this', where 'this' is typically running a set of
> tests. People use that answer to infer how 'safe' their system is because
> they
I said that coverage tools answer a specific question; 'how much of my code
is executed when I do this', where 'this' is typically running a set of
tests. People use that answer to infer how 'safe' their system is because
they equate test coverage and safety (which is often a flawed inference).
I took issue with you maintaining that Clojure automatically somehow
gives you insight into the coverage of your tests. Which it does not.
You still maintain this.
On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote:
> I have no idea why you aren't gushing. I'm not gushing, and haven't g
I have no idea why you aren't gushing. I'm not gushing, and haven't gushed
about anything technical for years because everything is a trade off and
has its own compromises/ceremony. I can see (and highly value) the
benefits of Clojure, sure.
If you want to write of my point of view as 'gushin
I don't come from 'Java-land'. I'm primarily an Erlang developer,
which already is a very similar language to Clojure. Perhaps this is
why I'm not gushing about functional programming's panacea?
Aaron
On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote:
> This has turned into an unconstru
This has turned into an unconstructive argument and for whatever reason we
don't seem to be communicating clearly. Shame as I (and probably most
people on here) only want to help. You seem to be reacting quite strongly
to my thoughts - not sure why.
If I may, I will just make/rephrase two poi
On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote:
> Comments in line.
> On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote:
> >
> >
> > I don't want to seem rude but I think you've drank a bit too much
> > kool-aid.
> >
> You know the phrase "I don't want to seem rude" doesn'
+1
I still force myself to write those tests simply for the confidence they give
me in replacing my hack with idiomatic code as I/colleagues get more familiar
down the road.
I can absolutely see dramatically reducing the number of 'safety rails' type
tests pretty soon; most of the code uses th
In clojure, generally I've found
Unit-tests are often significantly harder to write than the corresponding
implementing code,
idiomatic code rarely has silly problems,
and integration tests are enough to shake out bad behavior.
So, the end result is constraining our codebase at API boundaries wit
Comments in line.
On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote:
>
>
> I don't want to seem rude but I think you've drank a bit too much
> kool-aid.
>
You know the phrase "I don't want to seem rude" doesn't actually do
anything right? :)
> To say that functional programming an
My 2c - on my last project it would have been handy to have some test
coverage tools, they can be useful to sanity check your testing.
However, it's worth noting that compared to a java project, we had far
fewer lines of code, so manually reviewing code for tests was a lot easier.
And there were
I don't want to seem rude but I think you've drank a bit too much
kool-aid.
To say that functional programming and war against state means that
your application doesn't need to be tested thoroughly is a joke. And a
very bad one.
Coverage doesn't just aid you in seeing which parts of state caused
I don't know.
But maybe the lack of coverage tools is itself interesting? My (not quite
formed/making this up as I go) view is that maybe coverage tools are there
to address the implicit complexity in other mainstream languages and/or to
help mitigate the risk of the potentially large and hard
Hi,
I'm looking for coverage reporting in Clojure. I've been using
Cloverage[1] but I'm just wondering if there are any other coverage
tools?
Aaron
[1] https://github.com/lshift/cloverage
pgpMaXQ__7lWz.pgp
Description: PGP signature
16 matches
Mail list logo
