Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop mocking your system

blog.bitgloss.ro

Post reply on HN
Print view View original

41–50 of 178 posts

Re: Stop mocking your system

#41

Post by hendershot »

what the author is talking about in a short rant is classical vs mockist TDD.

for better content on the subject:

https://martinfowler.com/articles/mocksArentStubs.html

https://martinfowler.com/articles/mocksArentStubs.html#Class...

https://www.thoughtworks.com/insights/blog/mockists-are-dead...

"The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing."

I've been working in a classical TDD style for the past 8 years, after at least that many years of Mockist TDD. A code base built in classical TDD style is much easier to maintain and change, but it does require more test setup which can easily be pulled into re-usable test data scenarios etc. We'll use fakes for services that are external(S3, DynamoDB, third party APIs, etc), we'll use real DB code pointing to h2 instead of say postgres other than that there's no test doubles. I would not go back to using mocks by choice.

Re: Stop mocking your system

#43

Post by pydry »

EdSharkey wrote: post #40
pydry wrote: post #30

Earlier quoted context omitted.

>I think this is supposed to mean using dependency injection instead. I'm pretty sure he means "just use integration tests".

I think so too. Unfortunately, integration tests are too slow, so the practice doesn't scale if one is trying to TDD. Insinuating integration testing into every user story will lead to friction. Test run times will balloon, cycle times will get extended and resentment will grow for the test suite and the team's testing regime. If your test suites cannot complete quickly (seconds), then they cost more than they're wor…

I find I can do ITDD effectively with integration test times of What makes it work is pairing it with a REPL. That way I can have an "outer" loop that triggers the REPL and then an "inner" loop where I can experiment in the area where I'm writing the code and get feedback quickly.

I might run the outer loop just a few times:

* At the beginning of the ticket

* When I messed up the state with the REPL and when I want a fresh slate.

* When I've pasted code I think will hypothetically make the test pass from the REPL and I want final verification.

* One or two more times after that coz I missed something stupid.

Often the waiting times are a good time to get up and go for a walk/make a coffee/check my messages.

>I'm experimenting with sociable test

What's this? I'm unfamiliar with the term.

Re: Stop mocking your system

#44

Post by chris_j »

I used to use mocks an awful lot more than I do nowadays. I learned to do that style of testing from the book Growing Object Oriented Software, Guided by Tests (the "GOOS" book, which is still well worth a read, even if you don't subscribe to that style of test driven development). I'm still of the view that mocks are extremely useful if a) you're working in a highly object oriented style (where systems are composed of objects that communicate with their collaborators by method call) and b) you're unit testing relatively small units of code at a time. Mocks are very useful if it's important to you that object X must call object Y, do a computation and then call object Z with the result.

There are two key insights that helped me to eliminate the need for so many mocks: a) modern languages that support functional programming allow you to separate the concerns of computation and interaction with collaborators, and it's an awful lot easier to test drive a pure function that it is to test drive a graph of collaborating objects; b) modern hardware is sufficiently fast that it's much more feasible to spin up a whole service (or many services) in order to run tests on them, and you don't need to write fine grained unit tests merely in order to make the tests run quickly enough.

Re: Stop mocking your system

#45

Post by gjmacd »

Docker has made most mocking nonsensical considering how easy it is now to use the real thing... But I would disagree with the premise of mocking as being non-starter. Often times you want to unit test and don't really care if you're using the real "thing" but want to hit code that's got zero to do with that dependency. Good example, we use Okta to authenticate... We want to run unit tests that test how a component in our UI works within our application, we mock Okta to get around our authentication for testing that very thing. When we want to test authentication with Okta, that's what we do.

Re: Stop mocking your system

#46

Post by ramesh31 »

pydry wrote: post #30
drewcoo wrote: post #11

This blog post has tell us that we shouldn't use mocks but should instead "send data" to the code we are testing. I think this is supposed to mean using dependency injection instead. But the case isn't really made. Instead, with a waving of hands and wild assertions such as that I'm lying to myself, I'm left wondering what I just read. The previous post was on cargo cult programming. It warns that CCG is bad but can'…

>I think this is supposed to mean using dependency injection instead. I'm pretty sure he means "just use integration tests".

>I'm pretty sure he means "just use integration tests".

Really he means e2e testing. You can drive yourself mad writing integrations that break constantly or provide false positives. Better to unit test what is truly unit testable, and then rely on e2e to ensure your integrations are fine. Ultimately all that matters is the system running as expected at the user level.

Re: Stop mocking your system

#48

Post by alecbz »

jnaddef wrote: post #24

The author seems to believe people either mock everything or don't mock anything. Obviously using mocks for all your tests is a very bad idea, but that's not how things are done generally. Unit tests allow you to validate a unit's behavior very quickly. If your unit test takes more than 1 second to run it is probably a bad unit test (some would argue 1/100 second max so your whole unit test suite can complete in a fe…

I've certainly seen people who mock almost everything to test units at the smallest scale possible because they think that's what they're supposed to.

E.g., I once saw someone test a factory method like:

  def make_thing(a, b, c):
    return thing(a, b, c)
with a unit test where they mocked `thing`, and ensured that calling `make_thing(a, b, c)` ended up calling `thing(a, b, c)`.

They write just a shit ton of tests like this for every single method and function, and end up writing ~0 tests that actually check for any meaningful correctness.

Re: Stop mocking your system

#49

Post by [deleted] »

Supermancho wrote: post #36
astuyvenberg wrote: post #13

Earlier quoted context omitted.

For AWS specifically, I prefer to have an AWS account specifically dedicated to each service + stage. For example, if I have an image service that handles s3 uploads (say Lambda, S3, Cloudfront and API Gateway), then I'd deploy a "test" environment to a dedicated AWS account and run tests against that. Since it's fully serverless, it only costs a few pennies to test (or free). I try not to develop locally at all anym…

Why spend money on AWS you don't have to? Use Minio for S3 locally (or on your build server). Local development is the easiest way to avoid wasting money and resources on debugging/development.

[deleted]

Re: Stop mocking your system

#50

Post by astuyvenberg »

Supermancho wrote: post #36
astuyvenberg wrote: post #13

Earlier quoted context omitted.

For AWS specifically, I prefer to have an AWS account specifically dedicated to each service + stage. For example, if I have an image service that handles s3 uploads (say Lambda, S3, Cloudfront and API Gateway), then I'd deploy a "test" environment to a dedicated AWS account and run tests against that. Since it's fully serverless, it only costs a few pennies to test (or free). I try not to develop locally at all anym…

Why spend money on AWS you don't have to? Use Minio for S3 locally (or on your build server). Local development is the easiest way to avoid wasting money and resources on debugging/development.

Speaking from personal experience, our team wasted far more money tinkering with local dev environments and trying to replicate the cloud than we ever did simply using it to develop.

The blog post in the parent comment lays out our experience and my thoughts, but because of the pretty generous free tier, I don't think we've ever paid a penny for a build/dev/test AWS account.

Post reply on HN