Hi, I was wondering how you test functions that ar...

# announcements

[Bernhard]

Hi, I was wondering how you test functions that are private to a file? If you make it private you don't have access to it of course but public doesn't make sense since it's only used in that file

[Jonathan Mew]

I'm Interested to hear opinions because I end up wondering this too sometimes.

I would usually try to test the public interface of the module, because that's the level that should remain fairly stable. If I have complex logic and several private methods, it's probably quite a big class. Maybe you can split out a separate smaller class with more constrained responsibilities and public methods you can test?

Failing that, would it help to make the method internal?

[Bernhard]

yep, that's what I'm doing now but internal is kinda too generous imho

[Bernhard]

pollutes the global namespace

[tddmonkey]

If it’s truly private, you should ideally test through the public API or as you said, pull it out and make it public

[Stephan Schroeder]

Internal means restricted to module which is better than public but still a lot of visibility. If you work with interfaces than this (internal) method could be part of the implementation and not of the interface.

[Bernhard]

@tddmonkey you are right, however my usual approach is to use one integration tests for the simple case and a unit test once the internal implementation branches off too much

[Bernhard]

test suite is already slow enough

[tddmonkey]

I do the same thing - but my general rule of thumb is, if I branch off into a unit test, that code is made public/internal

[Bernhard]

or worded differently: pull out stuff into pure functions if possible and unit test that

[tddmonkey]

tbf, this was all a lot easier in Java - Kotlin has muddied the waters by giving us all these options 😄

[Bernhard]

in java you could have at least used package visibility afaik

[thana]

i'd say: you test it the same way, you test the private methods of class

[Stephan Schroeder]

C++ has the friend option, doesn’t it. So a method is private apart from the specified friend. This can be - of course misused - a lot but a testedBy would be convenient. But that leads to semantic test class which are allowed to be referenced by testedBy (in order to avoid the misuse of testedBy) which is a lot of baggage, so I understand why this doesn’t exist.

[thana]

just dont't test private stufff directly. it doesnt even make any sense

[thana]

test should use the very same api, the actual code uses. if it uses a different api you 1) test something different then the rest of the code uses and 2) tightly couple the testcode and the productive code.

arn;t we all striving to decouple things?

[Bernhard]

@thana that's a noble approach but your API often has non trivial amounts of code that you don't necessarily want to cover with an integration test (because they're sloooow)

I'm sure it makes sense to have API internal code that you want to cover with a unit test without mocking everything but that doesn't make sense to reuse in different locations

[Bernhard]

basically I'm lacking package/file visibility

[thana]

you dont need integration tests to do this

[thana]

unit tests are totally fine

[tddmonkey]

Personally I think you’re agonising over it too much. Mark it internal, test it directly and move on.