Do you guys think `@VisibleForTesting` a bad pract...

# android

[alex.tavella]

Do you guys think @VisibleForTesting a bad practice for unit testing internals of a component?

[Dmitry Chernozubov]

Yes, is bad practice. For example, create some test component with generic interface.

[alex.tavella]

I mean, if I want to test an internal method which will get called internally by another internal component, instead of setting up all that boilerplate up. I just set it @VisibleForTesting and unit test it directly.

[Matt Thompson]

I don’t think it’s so bad (especially after reading Working Effectively with Legacy Code), however the linting in Android Studio doesn’t seem to work for Kotlin like it does in Java

[Ray Ryan]

It’s a smell, but you gotta do what you gotta do

[Ray Ryan]

Generally a hint that you might be testing implementation details, or are missing some DI. When the landmine blows up it’s because you’re not testing the bits that call the method that should have been private.

[alex.tavella]

Agree, but in the tradeoff scale between boilerplate for setting up proper integration test and just testing this implementation details paid off in my case (at least in my opinion)

[alex.tavella]

Sometimes, building a integration test is so expensive that devs just don't do it.

[Cody Engel]

usually when i need to test functionality that’s inside of a component it’s a sign that i should extract that into it’s own class that the other class can rely on

[alex.tavella]

Fair enough

[Steve]

Keep in mind that now you’ve coupled your internal implementation to your test implementation, and now you’re not easily able to change the internals should the need arise

[alex.tavella]

Actually I have refactored it into a delegate + factory based on comments here. I was being really lazy and trying to justify my laziness