2,781 reputation
1227
bio website
location Argentina
age 37
visits member for 3 years, 7 months
seen 12 hours ago

Software developer and science fiction fan.


2d
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
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
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.
Aug
6
comment Many Arguments in Case Classes
I didn't downvote, but it looks like there are two different questions. Is it about constructors with many arguments, or about Scala case classes? :) I'd focus on one. The former sounds like it belongs here; the latter (which is narrower in scope and more technical) could be rephrased so that it belongs more on StackOverflow ("how do I solve this problem with Scala: (the problem)?"
Aug
6
comment Many Arguments in Case Classes
Note that case classes in Scala are a lot like tuples and are usually immutable (so no setter methods). So if Person(name: String, age: Int) is a case class, you more or less have to pass the parameters on construction. Having a PersonParams object would be pointless in this case. What would it be, another case class? In that case, you haven't really avoided the problem ;)
Jul
16
comment When does a Monad become a hammer?
@MasonWheeler You'd show you understood John Hughes if you quoted the part of his paper where he argues FP languages are "crippled" in regards to mutability, and that's why "you end up seeing monads everywhere". But I'm guessing you didn't understand the paper or his points :)
Jul
16
comment When does a Monad become a hammer?
@MasonWheeler I wish I could downvote your comment. Multiple levels of fail in it: 1- Monads are not only about controlling mutable state. 2- FP doesn't forbid mutation, but is all about controlling it. 3- Non-trivial programs can and have been created using immutable data structures.
Apr
23
comment Is test coverage an adequate measure of code quality?
@JoeRounceville I'm not sure... I can achieve high test coverage while testing nothing truly useful. Coverage merely tells you how much of the code is being touched by the test suite, not whether the tests are meaningful.
Apr
23
comment Is test coverage an adequate measure of code quality?
Testing is not a way to guarantee a program does what you intend.
Apr
16
comment How would another popular language avoid having to use the factory pattern while managing similar complexity as in Java/Java EE?
"In many dynamic languages" is a bit misleading, since what's actually needed is a language with first-class functions. "Dynamic" is orthogonal to this.