#testdoubles — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #testdoubles, aggregated by home.social.
-
Merry Christmas, to those who celebrate!
As a gift, the recording of my talk on "Testable Architecture" that I recently gave at the Calgary Software Crafters meetup is now available!
-
Merry Christmas, to those who celebrate!
As a gift, the recording of my talk on "Testable Architecture" that I recently gave at the Calgary Software Crafters meetup is now available!
-
"You need tests that don't break when you refactor. When you use dynamic mocks, tests tend to fail whenever you make changes in SUTs. Even though you have tests, they don't enable refactoring."
#softwareengineering #softwarearchitecture #tdd #unittests #mocks #testdoubles
https://blog.ploeh.dk/2022/10/17/stubs-and-mocks-break-encapsulation/
-
"You need tests that don't break when you refactor. When you use dynamic mocks, tests tend to fail whenever you make changes in SUTs. Even though you have tests, they don't enable refactoring."
#softwareengineering #softwarearchitecture #tdd #unittests #mocks #testdoubles
https://blog.ploeh.dk/2022/10/17/stubs-and-mocks-break-encapsulation/
-
I'm not trying to pick on #mockists, but as I point out in this #StackOverflow comment, mocks, #testdoubles, and stubbed methods don't always add value. In addition, this approach requires the rspec-mocks gem in addition to #RSpec core and expectations to create an RSpec::Mocks::Double, plus `allow(dbl).to receive` just to `expect(dbl).to receive`.
This is a layer of overhead and test indirection that is often unnecessary IMHO. YMMV, but it's often worth rethinking.
-
I'm not trying to pick on #mockists, but as I point out in this #StackOverflow comment, mocks, #testdoubles, and stubbed methods don't always add value. In addition, this approach requires the rspec-mocks gem in addition to #RSpec core and expectations to create an RSpec::Mocks::Double, plus `allow(dbl).to receive` just to `expect(dbl).to receive`.
This is a layer of overhead and test indirection that is often unnecessary IMHO. YMMV, but it's often worth rethinking.
-
If people actually read “XUnit Test Patterns: Refactoring Test Code” by G. Meszaros maybe they’d understand what test doubles are, or when/why to use them. Maybe they wouldn’t write how they hate “mocks”, but focused on merits of their approach.
There’s so much misunderstanding and non-constructive criticism in our profession. I really admire those few people I know who strive to write from a positive angle. I’m not sure if I’d be able to doit.
-
If people actually read “XUnit Test Patterns: Refactoring Test Code” by G. Meszaros maybe they’d understand what test doubles are, or when/why to use them. Maybe they wouldn’t write how they hate “mocks”, but focused on merits of their approach.
There’s so much misunderstanding and non-constructive criticism in our profession. I really admire those few people I know who strive to write from a positive angle. I’m not sure if I’d be able to doit.
-
What are the worst examples of using #testdoubles #mocks you’ve seen? Send me your mocking hell. #testing #tdd
-
What are the worst examples of using #testdoubles #mocks you’ve seen? Send me your mocking hell. #testing #tdd
-
I wrote something about testing at the boundaries of your application and contract testing
https://medium.com/@antodippo/testing-at-the-boundaries-of-your-application-fc78145bee9
#testautomation #contracttesting #testdoubles -
Breakdown of test doubles.
Test Doubles
Fake / Dummy:
- Actual implementation
- ShortcutStub:
- Canned answers
- Independent of testSpy:
- Like stubs
- Records callMock:
- Includes expectations
- Within test setup -
You can use #TestDoubles (#mockobjects) without using a library/framework just the same as you can use #DependencyInjection without a container.
You don't need to feel stuck, even though I can guess how to reached the point of believing you were.
-
You can use #TestDoubles (#mockobjects) without using a library/framework just the same as you can use #DependencyInjection without a container.
You don't need to feel stuck, even though I can guess how to reached the point of believing you were.
-
I routinely see programmers who shy away from using #TestDoubles/#MockObjects in their work. You can find so many strong opinions on the topic!
Let me offer another way to interpret one of the often-cited drawbacks of #TestDoubles and one of the often-cited advantages of testing with "the real thing".
https://blog.thecodewhisperer.com/permalink/a-matter-of-interpretation-with-mock-objects
-
I routinely see programmers who shy away from using #TestDoubles/#MockObjects in their work. You can find so many strong opinions on the topic!
Let me offer another way to interpret one of the often-cited drawbacks of #TestDoubles and one of the often-cited advantages of testing with "the real thing".
https://blog.thecodewhisperer.com/permalink/a-matter-of-interpretation-with-mock-objects
-
@jbrains have you seen Ian’s talk? https://youtu.be/EZ05e7EMOLM
Part of advice is to “Both develop and accept against tests written on a port”. They mean a port from hexagonal architecture. They’re strongly against mocks as they think mocks lead to testing implementation details.
I see this trend recently. However, It seems to me that this approach isn’t putting enough pressure on design and encourages bigger steps. -
@jbrains have you seen Ian’s talk? https://youtu.be/EZ05e7EMOLM
Part of advice is to “Both develop and accept against tests written on a port”. They mean a port from hexagonal architecture. They’re strongly against mocks as they think mocks lead to testing implementation details.
I see this trend recently. However, It seems to me that this approach isn’t putting enough pressure on design and encourages bigger steps. -
Further to my recent discussion about #TestDoubles/ #MockObjects in design, I remember asking this question at a SoCraTes event in Rochegude, France:
"Are method/function expectations an #OOP disease?"
(Or something similar.)
The short answer seemed to be this: it's quite OO, but maybe not a disease. In FP we sometimes contort ourselves to turn complicated custom workflows into straightforward function composition, and it's not always worth the effort.
-
Further to my recent discussion about #TestDoubles/ #MockObjects in design, I remember asking this question at a SoCraTes event in Rochegude, France:
"Are method/function expectations an #OOP disease?"
(Or something similar.)
The short answer seemed to be this: it's quite OO, but maybe not a disease. In FP we sometimes contort ourselves to turn complicated custom workflows into straightforward function composition, and it's not always worth the effort.
-
Further to this idea, whose videos on "evolutionary design without #TestDoubles / #MockObjects" would you endorse? I mean you really like them. You found them compelling and convincing. They don't have to be free.
-
Further to this idea, whose videos on "evolutionary design without #TestDoubles / #MockObjects" would you endorse? I mean you really like them. You found them compelling and convincing. They don't have to be free.
-
I'm mulling hosting an open discussion about the widespread antipathy towards #TestDoubles ("#MockObjects"), because I'd like to understand more about why others have this and I don't.
I'm worried about doing this, because people can act in a way that I prefer not to experience, especially when we try to discuss such issues.
I'm curious about three things:
- Would you attend this?
- Would you watch a recording of this after the fact?
- How would you handle the "bad behavior" issue? -
I'm mulling hosting an open discussion about the widespread antipathy towards #TestDoubles ("#MockObjects"), because I'd like to understand more about why others have this and I don't.
I'm worried about doing this, because people can act in a way that I prefer not to experience, especially when we try to discuss such issues.
I'm curious about three things:
- Would you attend this?
- Would you watch a recording of this after the fact?
- How would you handle the "bad behavior" issue?