2,780 reputation
1228
bio website
location Argentina
age 37
visits member for 3 years, 7 months
seen 40 mins ago

Software developer and science fiction fan.


38m
comment What should I do
This is off-topic here and will be closed. Please don't ask about career advice or which language you should learn. Read more here
38m
awarded  Informed
9h
comment Why has C prevailed over Pascal?
I wonder why this is the accepted answer, as most of the "facts" in it are wrong or at least strongly debatable (I think verbosity was irrelevant, for example). The wording is also odd, as it seems to imply C had a better object-oriented extensions than Pascal (!?). UNIX is the most likely answer and is not even mentioned here.
Sep
16
reviewed Approve suggested edit on Front end written in languages used for back end!
Sep
16
comment Static typing vs. dynamic typing
My recommendation is that you focus on a single question. As it is, this question is both too broad and unclear.
Sep
15
reviewed Approve suggested edit on Command line options style - POSIX or what?
Sep
15
comment How to change the alignement of contains in a JScrollPane
Isn't this question off-topic here? It looks like it belongs in SO.
Aug
29
comment Using Mockito.reset
(I'm not saying your test is definitely wrong, which is why I'm not posting this as an asnwer. It does look funny to me though)
Aug
29
comment Using Mockito.reset
I'm not very dogmatic, but usual unit testing practice recommends splitting the 3 tests, so that each unit test only has one reason to fail. I think it's confusing whether the first block is setup or test code because there is a verify in there. I would decide what it is; if it's setup after all, I'd put it in a @Before method.
Aug
29
comment Using Mockito.reset
This seems like a strange use of mocks. Why are you mocking RequestResponse? Also, the first block of code should be either setup or an actual test. Which one is it?
Aug
20
reviewed No Action Needed Is this a valid implementation of the repository pattern?
Aug
20
reviewed No Action Needed Dependency injection in constructor, method or just use a static class instead?
Aug
12
comment Protected variable & protected method in the era of TDD
Note that all relevant uses of innerStuff() are covered in unit tests for doSomething() :)
Aug
12
comment Protected variable & protected method in the era of TDD
Agreed about not breaking encapsulation, but a separate collaborator object doesn't truly break it. You build complex stuff by composing simpler stuff. Simpler stuff can and should be tested separately whenever possible, in a "divide & conquer" way. Black box testing has its difficulties, but you gain having less brittle tests -- and fixing brittle tests is a tremendous time waster.
Aug
12
comment Protected variable & protected method in the era of TDD
When innerStuff() is so complex that it makes sense to expose it to unit tests, you should refactor it as a separate entity and test it in its own test. Otherwise, your tests for doSomething() are enough.
Aug
12
comment Protected variable & protected method in the era of TDD
Actually it's more "I won't test private method innerStuff() directly, but since I'm testing all relevant cases for public method doSomething(), I'm also covering the private method. The key idea here is that all relevant uses of innerStuff() are being tested. If later I decide I no longer need it, I can safely remove it without breaking either tests or client code.
Aug
12
comment Protected variable & protected method in the era of TDD
I must side with @Doval here. Unit tests should be "black box" tests as much as possible; otherwise you're making them unnecessarily brittle. I don't want to update the unit test for method doSomething() when I only change its inner details, without changing its signature or specification. Private methods are by definition inner details and should almost never be exposed to unit tests (or other clients).
Aug
6
comment Alternatives to null values and option-like types
In which way is the Null Object Pattern better than an Option type?
Aug
6
comment Many Arguments in Case Classes
@Doval If you make the sole argument to a case class an anonymous object (using it to wrap multiple arguments), you're missing the main purpose of case classes: pattern matching. The idea is to pattern match like this: case Person(name, age) => ...stuff with name and age...
Aug
6
comment Many Arguments in Case Classes
@Doval Note that with Scala case classes, the order of fields matters.