4 ms·

> whats the point? suppose you are writing some software that interfaces with personal finance SAAS. except you want your users to be able to interact with mo

> whats the point? suppose you are writing some software that interfaces with personal finance SAAS. except you want your users to be able to interact with more than one. so you sure as shit better be testing that your abstractions are making the correct calls, especially if customer money is involved. you also really want to be testing for unreliability, for example, if your saas call is taking too long, you dont double tap, if a tx looks like it fails but it didnt actually, you know that on the second attempt, etc, etc. "the shell is untestable" is not an acceptable answer. and you cant wriggle out of this by saying "well that's an integration test". you said in your op "don't write mocks". thar is terrible advice in general. im generally a big fan of imperative shell functional core, but you MUST mock your shell, especially if absolute correctness is required (people's lives or money at stake)

ninetyninenine 2y ago
No. You completely missed what I said. I differentiated between unit tests and integration tests. Your imperative shell is not testable in the context of unit tests. However you must test it via integration tests. Mocks are a utility for unit tests hence the topic of this post. We are talking about unit tests and mocking aspects of the unit test that can’t be tested via unit tests. Integration tests are another topic. With integration tests or end to end tests you test everything. You don’t mock. Mocking is not really a valid concept in the context of integration tests.
- throwawaymaths 2y ago
  > However you must test it via integration tests. that is not what you said. you wrote: "Don’t code with mocks period" > I differentiated between unit tests and integration tests. you did not. your original comment doesnt mention integration tests at all. i quote: "Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should be Extremely general and as simple as fetching and requesting in the stupidest way possible. Then everything else should be covered by unit tests while IO is fundamentally not unit testable. If you have a lot of complex sql statements or logic going on in the IO layer (for performance reasons don’t do this if you can’t help it) it means your IO layer needs to be treated like a logical layer. Make sure you have stored procedures and unit tests written in your database IO language. You code should interface only with stored procedures as IO and those stored procedures should be tested as unit tests in the IO layer > Mocking is not really a valid concept in the context of integration tests. what the fresh hell are you talking about? its a common practice to set up mocks (using dependency injection with expects) for an external API call in an integration test. in 10 years of professional software development I've mocked in integration tests at five empolyers.
  - ninetyninenine 2y ago
    https://chatgpt.com/share/6773b196-7da8-8001-accd-aefbfe4bac3a https://chatgpt.com/share/6773b196-7da8-8001-accd-aefbfe4bac... Rarely used unless necessary is what I meant. The point of the integration test is to avoid mocking and I don’t want to argue a pedantic point with you and I also don’t like your attitude so I’m ending this section of the thread don’t bother replying.
    - throwawaymaths 2y ago
      hey man the least you could say us "yeah i wrote something that I didn't mean, my bad" when i called you out. instead you dug in, moved goalposts, and claimed you wrote shit you didn't. it started with literally bad professional advice. junior developers reading these forums need to not have professional habits influenced by the sort of behavior on display by you here. and a ChatGPT transcript? really? just do a simple search, you will find tons of articles advocating for mocking external apis in integration tests.
      - ninetyninenine 2y ago
        Ok. My bad. I have no problem saying that. But I cut off the convo because I don’t like your attitude. Didn’t like this reply either. Let’s just end it here I have nothing further to say to you and I don’t care about your technical opinions. Good day.

ninetyninenine 2y ago

No. You completely missed what I said. I differentiated between unit tests and integration tests. Your imperative shell is not testable in the context of unit tests. However you must test it via integration tests. Mocks are a utility for unit tests hence the topic of this post. We are talking about unit tests and mocking aspects of the unit test that can’t be tested via unit tests. Integration tests are another topic. With integration tests or end to end tests you test everything. You don’t mock. Mocking is not really a valid concept in the context of integration tests.

throwawaymaths 2y ago
> However you must test it via integration tests. that is not what you said. you wrote: "Don’t code with mocks period" > I differentiated between unit tests and integration tests. you did not. your original comment doesnt mention integration tests at all. i quote: "Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should be Extremely general and as simple as fetching and requesting in the stupidest way possible. Then everything else should be covered by unit tests while IO is fundamentally not unit testable. If you have a lot of complex sql statements or logic going on in the IO layer (for performance reasons don’t do this if you can’t help it) it means your IO layer needs to be treated like a logical layer. Make sure you have stored procedures and unit tests written in your database IO language. You code should interface only with stored procedures as IO and those stored procedures should be tested as unit tests in the IO layer > Mocking is not really a valid concept in the context of integration tests. what the fresh hell are you talking about? its a common practice to set up mocks (using dependency injection with expects) for an external API call in an integration test. in 10 years of professional software development I've mocked in integration tests at five empolyers.
- ninetyninenine 2y ago
  https://chatgpt.com/share/6773b196-7da8-8001-accd-aefbfe4bac3a https://chatgpt.com/share/6773b196-7da8-8001-accd-aefbfe4bac... Rarely used unless necessary is what I meant. The point of the integration test is to avoid mocking and I don’t want to argue a pedantic point with you and I also don’t like your attitude so I’m ending this section of the thread don’t bother replying.
  - throwawaymaths 2y ago
    hey man the least you could say us "yeah i wrote something that I didn't mean, my bad" when i called you out. instead you dug in, moved goalposts, and claimed you wrote shit you didn't. it started with literally bad professional advice. junior developers reading these forums need to not have professional habits influenced by the sort of behavior on display by you here. and a ChatGPT transcript? really? just do a simple search, you will find tons of articles advocating for mocking external apis in integration tests.
    - ninetyninenine 2y ago
      Ok. My bad. I have no problem saying that. But I cut off the convo because I don’t like your attitude. Didn’t like this reply either. Let’s just end it here I have nothing further to say to you and I don’t care about your technical opinions. Good day.