When to Mock • Hacker News Board

Re: When to Mock

#21

Post by commandlinefan » Thu, Apr 16, 2020, 1:55 PM UTC

jaitsu wrote: post #5

mabbo wrote: post #3

What bothers me about this article is that it doesn't really present alternatives or real-world examples of how to do what the author is saying. > Use real instances of managed dependencies in tests. Is the author suggesting I should spin up an entire instance of Oracle to run a single 50ms unit test? Because I often want to run my unit tests very frequently as I develop, ensuring I'm still green, etc. And my code ma…

Writing unit tests is debatable?

On HN, it's not debatable: you should definitely do it. Everywhere I've ever worked, it's also not debatable: no time or effort should be "wasted" writing unit tests, that's what QA is for.

Re: When to Mock

#22

Post by commandlinefan » Thu, Apr 16, 2020, 1:58 PM UTC

mumblemumble wrote: post #11

So, disclaimer: I'm about to focus on the finger instead of where it's pointing. Because that's what I feel like jabbering about right now. TFA isn't just about databases; it makes some interesting points on test practice in general, and is well worth a read. Anyway, A story I've seen all too often when mocking the database: A large development effort goes into creating test infrastructure. And then there end up bein…

> scads of bugs that weren't caught by the unit tests

Which is fine! Unit tests will never catch all the bugs - neither will type safety. Neither will code reviews. Neither will manual testing. But unit tests do catch the kinds of bugs that unit tests are good at catching, which eases the burden on the manual testers.

Re: When to Mock

#23

Post by xhrpost » Thu, Apr 16, 2020, 1:58 PM UTC

pgt wrote: post #2

Panic closed the tab when a giant form popup appeared asking for my email. Hate to add noise to the discussion, but I hope the author sees this and understands the market doesn't want this and reduces readership.

These kind of CTAs are everywhere these days and it's rather frustrating. Wish there was some solution to filter out sites that use completely not-ignorable (like in the corner) CTAs.

Re: When to Mock

#24

Post by BiteCode_dev » Thu, Apr 16, 2020, 1:59 PM UTC

This is one of the reason I don't like to put application logic directly in the database.

It makes everything harder: caching, testing, abstracting, balancing, etc.

Re: When to Mock

#25

Post by Tomis02 » Thu, Apr 16, 2020, 1:59 PM UTC

jaitsu wrote: post #5

mabbo wrote: post #3

What bothers me about this article is that it doesn't really present alternatives or real-world examples of how to do what the author is saying. > Use real instances of managed dependencies in tests. Is the author suggesting I should spin up an entire instance of Oracle to run a single 50ms unit test? Because I often want to run my unit tests very frequently as I develop, ensuring I'm still green, etc. And my code ma…

Writing unit tests is debatable?

Unit tests are code, and all code has a cost. Writing unit tests without any benefit is harmful behaviour. Real world example: testing dumb getters/setters.

Re: When to Mock

#26

Post by Tomis02 » Thu, Apr 16, 2020, 2:04 PM UTC

BiteCode_dev wrote: post #24

This is one of the reason I don't like to put application logic directly in the database. It makes everything harder: caching, testing, abstracting, balancing, etc.

Where do you draw the line between a query and application logic? Does a join or aggregate function count as application logic?

On another note, a few hours/days spent implementing application code can save you 5 minutes of writing SQL.

Re: When to Mock

#27

Post by doublesCs » Thu, Apr 16, 2020, 2:10 PM UTC

devit wrote: post #20

You should never mock anything. Test against the same dependencies that exist in production. If that's impossible (i.e. you get charged for the backends or you are controlling physical objects), then generalize the program to support alternative backends and frequently test only those that can work in the test environment, using some more ad-hoc methodologies for the others. Also, in general, if you need to change yo…

> Test against the same dependencies that exist in production.

Interesting. I said this at my work recently and I got a condescending explanation about how production things are production, we don't touch them. If we need stuff for development, those are dev things.

I now think that whether this is or isn't a good idea depends on specifics. Most often than not, I think it makes sense.

Re: When to Mock

#28

Post by uk_programmer » Thu, Apr 16, 2020, 2:10 PM UTC

jaitsu wrote: post #5

mabbo wrote: post #3

What bothers me about this article is that it doesn't really present alternatives or real-world examples of how to do what the author is saying. > Use real instances of managed dependencies in tests. Is the author suggesting I should spin up an entire instance of Oracle to run a single 50ms unit test? Because I often want to run my unit tests very frequently as I develop, ensuring I'm still green, etc. And my code ma…

Writing unit tests is debatable?

Yes. For a lot of smaller (web) applications where it is obvious if it isn't working correctly it just become a time sink. Everything in engineering is a set of trade-offs.

With regards to TDD specifically. It isn't for everyone and many consider it to be a bit of a cult. While I don't consider it a cult, It doesn't work with how I personally solve problems. I normally for example get something extremely rough working and then iterate until I consider it to be perfect and then write my tests to define how it should behave.

Re: When to Mock

#29

Post by packetlost » Thu, Apr 16, 2020, 2:14 PM UTC

Tomis02 wrote: post #25

jaitsu wrote: post #5

Earlier quoted context omitted.

Writing unit tests is debatable?

Unit tests are code, and all code has a cost. Writing unit tests without any benefit is harmful behaviour. Real world example: testing dumb getters/setters.

That's why I write large sweeping tests that make coverage metric to up, but don't take too much time to write or maintain /s

Re: When to Mock

#30

Post by detaro » Thu, Apr 16, 2020, 2:15 PM UTC

doublesCs wrote: post #27

devit wrote: post #20

You should never mock anything. Test against the same dependencies that exist in production. If that's impossible (i.e. you get charged for the backends or you are controlling physical objects), then generalize the program to support alternative backends and frequently test only those that can work in the test environment, using some more ad-hoc methodologies for the others. Also, in general, if you need to change yo…

> Test against the same dependencies that exist in production. Interesting. I said this at my work recently and I got a condescending explanation about how production things are production , we don't touch them. If we need stuff for development, those are dev things. I now think that whether this is or isn't a good idea depends on specifics. Most often than not, I think it makes sense.

I think parent means test against the same code, not against the same instance as production. Tests don't get to talk to the production database, but should use the same database software, deployed as similarly as possible, as production does. Against test/demo versions of APIs if possible. ...