This is not really by what the article is about IMHO. It’s a great overview of how to grow and organize your application with some opinionated patterns that give some favorable properties to your system. The nullable stuff just helps achieve those properties. If you want to use a mocking library to write nullables, and call them mocks, fine. Not important.
I only recently got into testing my code and while I love writing tests, getting started was kind of difficult because there was just so much noise. I eventually had to find one person to follow in my space (Kent C. Dodds) and just kind of go all in on his methodology.
(The most common question: isn't it the same as a mock? The answer is no, mocks are used for isolated, interaction-based testing, and this is for sociable, state-based testing. These are polar opposite approaches to testing with distinct tradeoffs. If you're not familiar with those terms, they're defined in the article in the "Foundational Patterns" section.)
At least at the scale of code I've been working with, it has been excellent. People keep threatening me with dire promises of how this or that testing practice will result in fragile, highly-coupled tests, and all I can say in response is that in 10+ years of continuously writing tests you'd think it would have happened to me by now. Instead I tend to make very reasonable changes to my tests as I go, and the only times I've ever ended up rewriting them top to bottom is when the underlying code under test changed so much that it was inevitable anyhow.
I tend to have a test module that sets up an entire test environment with all the stub implementations, which works fairly well in that middle ground between full integration and unit tests.
Testing Without Mocks: A Pattern Language - https://news.ycombinator.com/item?id=34293631 - Jan 2023 (76 comments)
Previously:
Testing Without Mocks: A Pattern Language (2018) - https://news.ycombinator.com/item?id=30565918 - March 2022 (28 comments)
Testing Without Mocks: A Pattern Language - https://news.ycombinator.com/item?id=16943876 - April 2018 (12 comments)
Then I learned about pytest, magicmock, and that the norm for other testing frameworks in other (mostly dynamic) languages is that you can replace whatever member or free function with a mock without this being part of the public interface of the original class or function. This feels insane to me, as this just tests implementation details.
Is there terminology to distinguish between these two kinds of mocking?
First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ?
Wait, i miss something here: Writing pure functions is hard ?
All this should be send to a task queue, triggered by a call to your REST API.
Good luck with purity.
> Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.
> So, how do you handle all this in a clean functional way?
> This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.
Functional programming keywords/shorthands: option/either/monads
Most of your counter example needs integration tests to test properly anyhow - not really a good point.
If you can give up encapsulation (which IMO isn't actually that useful in practice) and in return, your program becomes 95% functional, that seems like a really good tradeoff.
2. code that listens to the task queue for new jobs
3. code that fetches a file from the FTP server
4. code that converts the JSON file to a format appropriate for the root finding
5. code that performs the root finding
6. code that converts the result of (3) to a format appropriate for insertion into a table
7. code that inserts the result into a Postgres table
Steps 4, 5 and 6 seem easy enough to implement in a pure fashion.
However, solving a business problem with only pure functions is indeed hard
What I'd really like, is some way of acknowledging redundancy - lots of tests ultimately go through the same code underneath, it would be good if that could be tested only once, and then the data replayed from those points but done in such a way that everything is still nice and readable.
No.
Absolutely everything in the course is in the article. The benefit of the course is that you get to interact with me directly. You can ask for clarification, conduct exercises involving real-world code, and bring your own code for my feedback. It's a guided tour, but you don't need it. Everything is in the article.
One of the major benefits of automated tests is that they can provide a safety net that allows you to refactor with less risk of breaking behaviour. If tests get in your way of refactoring, because changing the implementation details of your SUT cause your tests to start failing, then the tests have failed at being a tool to facilitate refactoring.
Is there a difference between a fake and a "nullable"? As far as I can tell this is a pattern for merging your fakes and reals which seems cumbersome and error prone
>...For example, calling LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service.
So... a mock.
- limit side effects to your program boundaries
- abstract boundaries with utility functions
- mock program boundaries for integration tests in those utility functions
And then they pretend they didn't see the mock part.
Personally, I find it best to not be too concerned about the terminology, and make sure your test doubles get the data that the code under test needs to the place that needs it. The more real code you can involve in integration tests, the better; only look at replacing real code with test doubles if there is a performance or reliability downside. Databases have never hit that performance/reliability downside for me; network services do.
I second this. My experience is that some people know this terminology if they're actively learning or teaching the techniques, but most of the people I've worked with who know the techniques and apply them successfully don't know the terminology and use the word "mock" universally, so it usually creates more confusion than clarity to try to distinguish the different kinds of test doubles by name.
