On Wednesday, January 7, 2015 at 2:49:50 PM UTC-6, Sean Corfield wrote:
>
> On Jan 7, 2015, at 10:21 AM, Allen Rohner >
> wrote:
> > As a design rule, I prefer making I/O fns (things that hit the DB or a
> REST API), 'dumb', and perform all logic/processing in fns that just
> receive plain da
On Jan 7, 2015, at 10:21 AM, Allen Rohner wrote:
> As a design rule, I prefer making I/O fns (things that hit the DB or a REST
> API), 'dumb', and perform all logic/processing in fns that just receive plain
> data, and return plain data.
I’m curious: do you have wrapper functions for the DB rea
On Wednesday, December 31, 2014 8:48:27 AM UTC-6, Jonathon McKitrick wrote:
>
> I use TDD and mocking/stubbing (conjure) to test each layer of my code.
> The problem is when I change the function signature and the tests do not
> break, because the mocks/stubs do not know when their argument li
Akos Gyimesi wrote:
every function call has a
corresponding mock call in the test, so whenever you modify the
implementation (without even changing the top-level result) you have to
modify the tests as well, and vica-versa. I once encountered a codebase
that had thousands of lines of such "tests"
Akos Gyimesi wrote:
Now, later that day I decide that I pass the whole user object to the
check-pw function. Maybe I want to use the user ID as a salt, or maybe I
just want to leave the possibility for checking password expiration,
etc. So I modify the test and the implementation of check-pw so
Thank you for all the responses! To be honest, I hoped that someone
would explain why this mocking style is a good thing, and I just
misunderstand something about the "top-down development" that the Midje
wiki suggests:
https://github.com/marick/Midje/wiki/The-idea-behind-top-down-development
Wh
+1 - I think we are saying the same thing (not sure if you meant to
reply to me?)
On 6 January 2015 at 14:35, Timothy Baldridge wrote:
> I think the answer to questions like this is that you are testing the wrong
> thing, or more correctly you are writing incomplete tests.
>
> In your example, yo
I think the answer to questions like this is that you are testing the wrong
thing, or more correctly you are writing incomplete tests.
In your example, you stubbed out check-pw. But calling check-pw has a
contract, a contract that (at the moment) only exists in your head, but a
contract none-the-l
I don't think there is an easy answer here, and note that this is a problem
generic to mocking (i.e. not clojure or midje specific).
The usual advice applies though:
- do you really need to mock? Unit testing is about the coarseness of
granularity which is defined more by cohesion and abstract
Akos,
that is exactly the kind of problem I'm talking about! Right down to the
detail about stopping work and returning to the project later, and seeing
all the tests pass!
--
Jonathon McKitrick
On Tue, Jan 6, 2015 at 3:22 AM, Akos Gyimesi wrote:
>
> On Sat, Jan 3, 2015, at 02:46 AM, Brian M
On Sat, Jan 3, 2015, at 02:46 AM, Brian Marick wrote:
>
> > I use TDD and mocking/stubbing (conjure) to test each layer of my code.
> > The problem is when I change the function signature and the tests do not
> > break, because the mocks/stubs do not know when their argument lists no
> > longer a
>> I think you are coming across a bit strong
That's probably true. At the end of the day I believe that tests should be
written in the same language with the same semantics as the code they are
testing. Midje does not recommend this. It is a multi-thousand line
compiler that transforms a DSL int
Agreed, Timothy - obviously the mental model gets more tangled when
state mocking comes into play, but the fact is, sometimes you don't have
the option (right away) of rewriting the code you're testing.
Midje has been great for the Cascalog community:
http://www.samritchie.io/testing-cascalog-w
(Happy new year all!)
I have thousands of lines of tests written using Midje and it was the
second one I turned to when I started using Clojure full-time a couple of
years ago. I think it would be fairer to say that Midje is powerful enough
to hang yourself, but that doesn't make that power wro
Timothy Baldridge wrote:
Stuff like with-redefs and providing muck with a developer's mental
model of the source code. So instead of being able to say "well foo
calls baz here, so this should work". They have to think "well foo calls
baz unless someone re-deffs it, in which case I haven't a clue
Timothy Baldridge wrote:
I assert that a simpler library, something that only provides deftest,
assert and run-tests forces developers to think about the best way to
test something, and to write their own macros (as patterns emerge)
A not-unreasonable idea. Midje supports that by also running
>> Hacker News notwithstanding, "idiosyncratic interface" is not a synonym
for abomination.
True, however, reaching into code, and re-deffing a function's definition
is. Not only is it not thread-safe (removing the possibility of ever
running two tests in parallel), but it also hides main problem.
Timothy Baldridge wrote:
I don't recommend Midje at all. Many of the framework's mocking
facilities (such as providing) are abominations.
Hacker News notwithstanding, "idiosyncratic interface" is not a synonym
for abomination.
It may look cute,
but I've lost countless hours to bugs and un
I use TDD and mocking/stubbing (conjure) to test each layer of my code.
The problem is when I change the function signature and the tests do not
break, because the mocks/stubs do not know when their argument lists no
longer agree with the underlying function they are mocking. Is there a
way to
On Dec 31, 2014, at 8:24 AM, Timothy Baldridge wrote:
> This is one of the main reasons why I try to stay clear of heavy use of
> invasive mocks. I can't tell you the amount of times I've looked at code and
> realized that because of mocks nothing was really being tested at all.
> Instead, thin
This is one of the main reasons why I try to stay clear of heavy use of
invasive mocks. I can't tell you the amount of times I've looked at code
and realized that because of mocks nothing was really being tested at all.
Instead, think of mocks as the terminator in a test chain. That is to say,
they
I've always done the full database setup and tear down thing, but that's made
sufficiently performant with datomics in memory store. Consider using
transactions to isolate tests, or use Midje, which is more designed for this
kind of usage.
--Ashton
Sent from my iPhone
> On Dec 31, 2014, at 9
22 matches
Mail list logo
