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

81–90 of 178 posts

Re: Stop mocking your system

#81

Post by rileymat2 »

arkh wrote: post #73
alecbz wrote: post #51

True "unit" tests are: * faster to run * give you less confidence in the correctness of the system (per time spent writing them) * when they fail, give you more information about where the failure is The more integration-y/e2e-y a test is, the more it strays from this: slower to run, more confidence that the system is correct, less info about where the failures are. I think people have learned to undervalue the prope…

Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. And if you don't have enough e2e tests, you have nothing to check your refactoring efforts have not broken anything.

Do they hinder refactoring or rewriting?

When I am doing legitimate refactoring in simple steps by the book, unit tests are helpful and speed it up. When I am rewriting, I see your issue.

For example, a sprout method or sprout class refactor do not change the tests.

Re: Stop mocking your system

#83

Post by hamandcheese »

arkh wrote: post #73
alecbz wrote: post #51

True "unit" tests are: * faster to run * give you less confidence in the correctness of the system (per time spent writing them) * when they fail, give you more information about where the failure is The more integration-y/e2e-y a test is, the more it strays from this: slower to run, more confidence that the system is correct, less info about where the failures are. I think people have learned to undervalue the prope…

Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. And if you don't have enough e2e tests, you have nothing to check your refactoring efforts have not broken anything.

If a test is in my way, I delete it.

Re: Stop mocking your system

#84

Post by samatman »

I would make an exception for SQLite. Here's how you do it:

- Write your schema so it's compatible with SQLite and your production DB, such as PostgreSQL.

- When you're running tests, use SQLite instead of Postgres to run those tests.

- Use SQLite in production. Go ahead, do it. You don't need Postgres, SQLite is fine. I promise. Trust me

Re: Stop mocking your system

#85

Post by teddyh »

sdeframond wrote: post #65

Recently, I thought about a process I call "Test Coverage Driven Testing". It is similar to TDD, but more adapted to when we write tests after the code (you know you do too, at least occasionally, don't lie). It goes roughly like this: - write one integration test for the "happy path". - using some test coverage report, identify untested cases. - write unit test for those. I find I helps me find a good balance betwee…

> - using some test coverage report, identify untested cases.

From what I understand, that is not reliable; a line of code can be “covered” – i.e. executed – but still not be tested under all circumstances. If you have pre-existing code you need to write tests for, what you need is probably a tool for mutation testing.

Re: Stop mocking your system

#86

Post by bluepizza »

tuxie_ wrote: post #75
bluepizza wrote: post #4

Earlier quoted context omitted.

Why?

Hey bluepizza. As I wrote in response to another comment, I think that too much mocking (and/or mocking in the wrong places) is a code smell. I was not aiming to define what a unit test is, more like when it stops being a unit test, and I think that if you have to mock, for example, a DB call inside your business logic, well you are writing an integration test at that point, whether or not you mock the DB out. If you…

But if you include a real DB on your business logic testing, that's not unit testing anymore, is it,

Re: Stop mocking your system

#87

Post by detaro »

tuxie_ wrote: post #72
catwind7 wrote: post #3

Earlier quoted context omitted.

what does unit testing have to do with whether or not you instrument the test with fake responses? those points of contact that you're mocking out at the perimeter, that data will sometimes need to reach a particular function through a collaborator...which you may want to mock? sometimes the dependency is not a third party, but it may be code that requires a ton of setup (as mentioned in article) that's not worth the…

I'm sorry, I did not intend to offend anyone obviously. Needless to say, this is just my opinion condensed in a sentence (therefore lacking a lot of context, which I should have provided). I was not aiming to define what a unit test is, more like when it stops being a unit test (which I thought it would be an easier agreement to reach than a definition of what is, but I guess I underestimated the task). My point was…

So components that talk to the outside can't be unit-tested at all?

Re: Stop mocking your system

#88

Post by tuxie_ »

bluepizza wrote: post #86
tuxie_ wrote: post #75

Earlier quoted context omitted.

Hey bluepizza. As I wrote in response to another comment, I think that too much mocking (and/or mocking in the wrong places) is a code smell. I was not aiming to define what a unit test is, more like when it stops being a unit test, and I think that if you have to mock, for example, a DB call inside your business logic, well you are writing an integration test at that point, whether or not you mock the DB out. If you…

But if you include a real DB on your business logic testing, that's not unit testing anymore, is it,

Exactly. It may sound ridiculous but it happens all the time. You dig into the "unit tests" of the app and you find mocks for a db call, or an API call, or the system's date, or environment variables that some other part of the system will break if they are not defined (or all of the above). That's what I mean, these are all code smells that the code is highly coupled.

Re: Stop mocking your system

#89

Post by tuxie_ »

detaro wrote: post #87
tuxie_ wrote: post #72

Earlier quoted context omitted.

I'm sorry, I did not intend to offend anyone obviously. Needless to say, this is just my opinion condensed in a sentence (therefore lacking a lot of context, which I should have provided). I was not aiming to define what a unit test is, more like when it stops being a unit test (which I thought it would be an easier agreement to reach than a definition of what is, but I guess I underestimated the task). My point was…

So components that talk to the outside can't be unit-tested at all?

Hi detaro. Good question. If all my module does is make an api call, and I mock the API, what am I testing? I would rather leave that out of the unit tests because the added value is, in my opinion, close to none if you are relying on mocked data.

Now, if the module does more than just call the API then I would argue that it's breaking the single responsibility principle and would prefer to split it into a module that does only the call and another that does the rest.

Re: Stop mocking your system

#90

Post by detaro »

tuxie_ wrote: post #89
detaro wrote: post #87

Earlier quoted context omitted.

So components that talk to the outside can't be unit-tested at all?

Hi detaro. Good question. If all my module does is make an api call, and I mock the API, what am I testing? I would rather leave that out of the unit tests because the added value is, in my opinion, close to none if you are relying on mocked data. Now, if the module does more than just call the API then I would argue that it's breaking the single responsibility principle and would prefer to split it into a module tha…

Ok, then go one level in: If a component uses the "only makes an API call module", how do I unit test it? I can't let it use the module to make the API call (because the API might not be available in testing/that's an integration test/...), and I can't mock it, because using a mock would make it a not-unit test? I guess this gets at the line between mocks and stubs, but I never found that all that convincing.
Post reply on HN