Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write tests. Not too many. Mostly integration

blog.kentcdodds.com

Post reply on HN
Print view View original

201–210 of 338 posts

Re: Write tests. Not too many. Mostly integration

#201

Post by hacker_9 »

Jach wrote: post #191
hacker_9 wrote: post #78

Earlier quoted context omitted.

Simply because you can't mock the static dependency, therefore that method is now dependent on the static class and you don't have any control over it. This is problematic - what if at some point later another developer adds a database call into the static method to do some logging? Now your testing will dirty whatever database you're using, as well as run 10x slower - and yet the test will still pass and everyone wi…

In Java, you can use PowerMock to mock or spy anything, even private static final things. I consider it a smell (though excessive mocking even without powermock is its own smell), but it's immensely valuable to get code you can't change (or fear changing because of its complexity and lack of tests, or simply don't have time to change because the refactoring would take a whole sprint) to have some tests. You don't nee…

In C# we have Moq that can mock normal classes, though it requires adding 'virtual' to every method you want to override which is a code smell too. In Java everything being virtual by default I guess it doesn't matter. We like to always keep an interface around as it gets the developer used to working that way and keeps the code consistent. Visual Studio provides a quick shortcut to auto gen the interface too.

Re: Write tests. Not too many. Mostly integration

#202

Post by profalseidol »

sbergot wrote: post #46
hinkley wrote: post #3

Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests…

In some situations unit tests with lots of mocks will bring a negative value. Imagine a situation where you want to refactor a big piece of code with many dependencies but you don't want to change its public interface. If you mock everything, when you refactor, the test will break because the dependency structure will change, and the mocks are no longer relevant to the new implementation. You have to rewrite the test…

I agree with this.

Although, if you offshore development here in the third-world where internet gets slower everyday. Running an integration test that queries to Amazon RDB can take forever.

I hope this issue gets a spotlight and be noted that integration tests in third world countries is very very slow. And this high cost should be included in the estimates.

To give you an idea, here it takes AT LEAST 5 seconds to load a page from the amazon console. Lol, even the software companies owned by the ISPs/Telco here complains that their access to AWS is super slow. They said that bad routing is the main issue and for some reason the ISP isn't doing something about it.

Re: Write tests. Not too many. Mostly integration

#203

Post by wolco »

lucidguppy wrote: post #124

Clean architecture: https://smile.amazon.com/Clean-Architecture-Craftsmans-Softw... Anything that touches the real world should be as small as possible. I've been writing code using tests for about 4+ years and I now can't think of writing code any other way. I would be scared of refactoring. Also I'm testing the code anyway - why not write it down so it gets done every time? Run integration tests too for sanity - th…

The problem with always relying on testing is you lose your ability to create without the test crutch. Everything is red/green and your brain can get a lazy. Balance is the best.

Re: Write tests. Not too many. Mostly integration

#204

Post by pault »

maxxxxx wrote: post #186
pjmlp wrote: post #82

Earlier quoted context omitted.

Is GUI code that 0.1%? Because I am always keen to understand how to TDD GUI code and I don't mean the data model behind the pixels.

To a certain degree you can unit test GUIs with tools like Ranorex or Selenium. The question is how much setup you need to get the GUI on the screen with the right data.

That isn't unit testing though, it's integration or e2e testing.

Re: Write tests. Not too many. Mostly integration

#205

Post by vertex-four »

hacker_9 wrote: post #182
viraptor wrote: post #172

Earlier quoted context omitted.

> Now your testing will dirty whatever database you're using, as well as run 10x slower It sounds like a problem is a few layers higher. Why is there a live database in your unit testing environment? Why are working credentials configured? If they're unit test, not integration tests, all db operations should be DId / mocked / whatever. Any call that isn't should fail, not take longer time. Db interaction is for the i…

That's exactly my point, mock your external dependencies. Static calls don't allow you to do that.

So how exactly do you test that your SQL query does the right thing? That you're using the Twitter API correctly?

Re: Write tests. Not too many. Mostly integration

#206

Post by TimJYoung »

The one thing that I didn't see mentioned is the fact that you can test very specific branches of code with higher-level testing, but the same cannot be done in reverse. In fact, higher-level tests, especially tests driven with real--world data, routinely execute branches of code in ways that are unforeseen by the developer and unlikely to have been tested at a lower level. I suspect that fuzz testing will some day remove much of the need for lower-level testing.

Re: Write tests. Not too many. Mostly integration

#207

Post by ndh2 »

_0w8t wrote: post #57
pleasecalllater wrote: post #33

Sounds good in theory. In practice there is one problem with having integrations tests only. The test are generally simple: they pass or they fail. A unit test tests just a small functionality, so when it fails, it's quite easy to find out the problem. When an integration test fails, then we can spend hours debugging the whole stack of layers trying to find out the real problem. I had this situation once. Every faili…

From my experience an integration test failure that requires significant efforts to investigate can only be covered with unit tests after one knows where the problem comes from. One cannot realistically write a bunch of unit tests and expect them to cover the problem unless one already knows about the problem.

It's called shotgun unit testing.

Re: Write tests. Not too many. Mostly integration

#208

Post by profalseidol »

josteink wrote: post #4
hinkley wrote: post #3

Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests…

I work in a company where quite a few of the developers simply are incapable of writing anything but integration-tests. The reason? They don’t “believe” in unit-tests. They don’t think unit-testing “works in the real world”. They absolutely fail to accept that they need to write their code differently for automated testing to work well. How do you change such a mindset?

The keyword is "believe".

Such behavior is not science. In science, you don't believe, you understand not faith. You check evidence, you use reason.

A mindset that relies on "believe" but not on reason. It maybe because of decades of advertising. Can be a side-effect of participating in believe movements.

How do you change such a mindset? For me, it was reading lots of philosophy and atheist vs theist debates. For Socrates, he died for it.

Re: Write tests. Not too many. Mostly integration

#209

Post by rb808 »

MichaelMoser123 wrote: post #39

The problem with this kind of advise is that projects are all very different - there is no one fit way to test it.

Absolutely - this is the key. There is a huge difference in the software for a game engine vs a website vs an MIS report vs a trading system vs an autopilot. You can't blanket statement which testing technique is better for all software.
Post reply on HN