Some dev makes a claim that a Serialization library won't serialize a field unless it's public

I don't know the library details after but first reaction was "that has to be BS...."

Then I just do a Google search and yes I'm right.

And of course, in my head I go...why the fuck do these ppl not know how to use Google or just RTFM.....

Or use their brains.... If need for serialization required making all fields public that violates the most basic OOP principles...

I can proudly say, that I was too retarded to go look for a Serialization Library and thus wrote my own.

Yes but what the fuck, people apparently forget that they have all the world's information literally on hand.

Sadly, that's common for all these new serialization libraries, that are based on reflection, rather than a serialization-state or intermediary objects.

@metamourge well for enterprises programming, it shouldn't be used.

We're only supposed to use industry standard libraries and this was an old one, Jackson (Java) so that's also another reason why I'm like wtf that can't be right...

Also seems to show devs have no desire to improve themselves...

@metamourge reflection though can see all data even private?

I used to use PowerMock so I could unit test private methods...

Never figured out how u can unit test all methods of a class since many arent supposed to be public

@billgates
In all reflection implementations I've seen so far, you can access all members, no matter their visibility.
However, most reflection based serialisers are build around the idea, that only public members are supposed to be serialised.

They probably mean that many serialisation libraries won't serialise a private field without a public accessor (at least with default settings, you can reflect your way around it.)

I believe Jackson falls into that camp also.

Oh, and please don't unit test private methods...

@AlmondSauce yes that's what I mean, just needs a public getter but that dev didn't do basic research...

But say u have a class that does a lot of calculations but the only public method is calculate(Data d)

The actual method calls many other methods but it's proprietary or depends on the the current state of fields with the class.

How can you unit test all the private methods individually?

@billgates I'd say you don't - you just test the public interface of the class. You should be able to (correctly) change the private implementation without causing unit tests to break.

@AlmondSauce but say the function has a lot of IFs. So in order to get 90% coverage, would need to create all sorts of test cases and I guess tweak them just so a certain path is hit.

Where as if you test each private method, it would be like if A, B are good. Then function C that calls A and B can assume any error while resting C is due to C, not A or B?

@billgates Then I'd say you've got bad design. Methods with bunches of "ifs" are seldom great from a design perspective, nor are methods doing a whole load of different things. It's a code smell often seen in code bases where unit testing wasn't a consideration.

Best would be to split up responsibilities, move each of them into separate classes and unit test those. (They can of course be package private rather than public if it makes no sense to use them elsewhere.)

@AlmondSauce Current project involves populating an Excel workbook with precalculated values.

And there are different types of rows and like 50 columns.

So for each type of row I have a set of inputs that I pass to XRowCreator.createRow(...)

And it computes each column and stores the value in a property.

So internally there like 50 calculate... Methods.

How do you write a unit test for each?

From the calling class, there is no reason to call each and but for testing, I want to validate each calculate function individually

@billgates Difficult to say without seeing the whole code, but the most "normal" approach might be to make the top level calculator an interface, then have implementations of that interface for each type of row. Those implementations can then be unit tested individually.

@AlmondSauce maybe it really depends the architecture of the app. Interface approach feels more like for DI frameworks where you expect components to be changing alot and swappable. I remember there was some MS framework where u define a Repo of components for each Interface so each to refer s to the interface it binds it to the implementation.

But I've already found it difficult to follow for code you don't expect to change much.

Creating interface and impl feels like overkill...

@AlmondSauce so it turns out you are right at least for creating unit tests for the latest app I wrote. The only function is createReport which reads a json file of another report as an input (converts it to a POJO)

So all I really need to do is generate a smaller test report that covers all or 90% of the routes and just call that one method...

But still that only covers test coverage... Still need to validate all the output values...

Guess that's doable by loading the expected output json and comparing all the values... But that's sort of cheating?

I think this is me like a regression test vs a unit test though

@billgates Doing the whole thing and comparing against a set of values sounds more akin to an integration test. It's very valid, but it should supplement unit tests, not replace them.

Unit tests should just take each "unit" of code (usually each public method in practice) and run each scenario through them (happy scenario, invalid input scenario, error scenario, etc.) to make sure the behaviour of that particular unit is as you expect.

Public fields should be used if it is an DTO. And an DTO has no logic.

For excel exports it makes sense to split the raw export functions (anything the excel library offers or is related to it) from the actual data generation.

I usually write an QND CSV exporter before tackling excel, as CSV is as plain and dumb as it can be.

Most of the time there are DTOs that hold the values for either export.

These DTOs are fed into the actual export.

In the exporter implementation you'll just take the values and fill.

The factory methods for the DTO's and the DTO's itself can be Made specific to one exporter type (e.g. excel)… as sometimes you'll have to deal with a lot of weird shit (Localization, unit conversion, ...)

From testing view, you would test the factory methods. As they should contain the relevant logic. The exporter should be (as much as possible) only dealing with outputting the data.

@IntrusionCM I don't recall but I think it was more than a DTO. Some of the fields are calculated. And well other other thing is just convention.... In Java, most IDEs can generate the Getters. Making all fields public is a JS, Python thing...
(For some reason when I swipe "fields" my kb picks girls instead... But now it picks... Dorks)