On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
While you might say that a unittest shouldn't acces private members and only public members, there are plenty of testcases where one would want to write a unittest to set a given variable via public function and then test if the appropriate private fields are properly set. While this sounds like a trivial usecase I believe it to be a verry big one in practice since it removes a lot of boilerplate code from your unit-tests, together with exposing the innards of a class's implementation to the outside world just so you can unit-test it.
I have to ask, why isn't that unittest your talking about, within the scope of the class? Why is it outside the class, testing private innards of the class?
I have trouble getting my head around this.
The last point is something I don't like about OOP + TDD in languages like C# or java and I think D has (accidentally) solved this in a beautiful way, and I would dislike to see this feature go.
I'm not sure I understand this. You mean you don't like 'private'? You think an object doesn't have a right, to privacy? Are you one of those facebook employees? And who suggested getting rid of anything?
