Private testing

If you do testing, then, like me, at one time you probably came up with a question "How do I test private methods?". The tricky part about private testing in static languages like java, is that you can't access private methods from outside.

There are couple of ways to test private methods. You can do it through reflection, you can easily find libraries which ease the syntactic pain. Or you can make it package-private, this way you can use them in your tests, but users of your library still can't see it (though it can turn your own package into a tangled mess).

And both things are WRONG! And many people know it. Go to stack overflow and you will see lot of upvoted results, how it is "implementation detail, don't test it".

In my opinion, you should test this kind of methods. If you closed your IDE/Editor of choice and opened Google, then chances are it's important enough to have a unit test. Do you smell it? I certainly do... And it's coming from your code!

If you want to test it - then it's important, if it's important, than why isn't it in your public API? Because class users don't care about, it's not class's responsibility. If it's not your class responsibility then go create a new one. Now you can test it all you want and then refer to it from the original class. Noisy teenager moved out from parents and has a separate life, the end.

At first glance people who use Ruby, Python and other dynamic languages without a strong notion of privacy are happily neglected to this problem. You can use private methods as easy as the ones that intended to be public. That's actually very scary. In Java on every method creation you have to decide whether it's private or public. If you don't have to do this you might end up with a bunch of monster classes (been there, done that, not proud of it).

Popular posts from this blog

HTTP server in Ruby 3 - Fibers & Ractors

Next.js: restrict pages to authenticated users

Migration locks for TypeORM