2,773 reputation
1230
bio website
location Argentina
age 38
visits member for 3 years, 11 months
seen 3 hours ago

Software developer and science fiction fan.


Sep
26
comment Is there a good reason to make pure functions non-public?
To clarify, I'm agreeing with this answer.
Sep
26
comment Is there a good reason to make pure functions non-public?
@Telastyn I think integer "less than" is not a good example, since it's a function that everyone agrees is part of the "public API" of integer numbers. In the general case, when you make something public it's harder to remove it later; private/public is more about "things that I can freely change with impunity" vs "things that are difficult to change". No-one would dream of removing integer "less than", but when you're coding anything else, you have to think about whether it's likely to change and/or disappear, and this is orthogonal to its "purity" (in the sense of the original question).
Sep
26
comment Is there a good reason to make pure functions non-public?
What was your opinion? I don't think the purity of the function is related to whether it belongs in the public API.
Sep
25
comment Is Testing a necessary part of Agile methodology?
@Snowman Testing != unit testing. Also, unit testing != TDD (just in case...).
Sep
25
comment Is Testing a necessary part of Agile methodology?
I'd say testing is absolutely essential for software development.
Sep
25
comment Is Testing a necessary part of Agile methodology?
I agree with @BartvanIngenSchenau. Not only is testing a far broader activity than just doing TDD, but TDD and unit testing are not the same. I'm surprised so many people confuse the last two.
Sep
24
awarded  Autobiographer
Sep
24
reviewed Approve Good 'real life' example of operator overloading C++
Sep
19
awarded  Informed
Sep
19
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 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 Command line options style - POSIX or what?
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
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.