Skip to main content
16 events
when toggle format what by license comment
Oct 24, 2017 at 3:55 comment added jpmc26 static code doesn't automatically make unit testing harder. Static dependencies do in some cases, in languages where you can't stub out anything but instances (e.g., Java and C#). However, even in those languages, static code that can be unit tested purely via input and output is not more difficult to test, and static method calls that are best regarded as implementation details that the unit test should not care about also don't increase the difficulty.
Oct 23, 2017 at 18:32 comment added CodingYoshi @S.R. You can create a new object without new using IoC container (underneath it will call new at some point but your code is not tied to it.) This will be done at the composition root level and its okay if at that level you commit to concrete implementation. I think you are digging too deep into this and without getting your hands dirty and actually writing code and then writing unit tests or TDD, it will be really hard for you to grasp these topics. Just write some unit tests and you will see it for yourself.
Oct 23, 2017 at 15:43 comment added David Arno @S.R., well you can't. But a slightly different question, "how would you supply an object without new?", then the answer would be, eg use an object pool, or with C# for example, you could use stack based structs to avoid hitting the heap. But as I said previously, that's all pointless pendanticism, so just ignore what I said ;)
Oct 23, 2017 at 15:11 comment added David Arno @whatsisname I know. I just let whine and ignore them. :)
Oct 23, 2017 at 14:39 comment added whatsisname @DavidArno: If you have any class that utilizes those pure static functions, some people will whine that your unit test is now an integration test.
Oct 23, 2017 at 12:49 comment added user286462 @DavidArno - how would you create a new object if not with the new keyword?
Oct 23, 2017 at 12:33 comment added David Arno @S.R., the side-effects of using new are that it impacts upon the heap and thus potentially the GC. But upon reflection I'm being needlessly pedantic. So I'd suggest ignoring that statement from me :)
Oct 23, 2017 at 10:56 comment added user286462 @DavidArno - Still learning here, so what are the side effects of using new? How would I create a new Weapon without using new?
Oct 23, 2017 at 9:42 comment added David Arno Clearly the factory methods in the question call new, they have side effects. However, that side effect is identical to just calling a public constructor, so they are no more difficult to test than the latter.
Oct 23, 2017 at 9:40 comment added David Arno Downvoting this answer as it is fundamentally a flawed answer. Static functions only make testing harder if they are non-deterministic and/or have side effects. The argument in the link provided that "Unit-testing assumes that I can instantiate a piece of my application in isolation" is complete nonsense: unit testing is simply testing parts of the code in isolation. If a static method is pure (is deterministic and has no side effects) then it is as good a candidate for unit testing as one can get as it inherently executes in isolation.
Oct 23, 2017 at 1:46 comment added CodingYoshi @S.R. You do not need a factory to create immutable objects. I suggest you throw away the factory and only use it if you ever need it. Using design patterns can (often it does) complicate your code. Only use it if you have a need. I honestly do not think you need it in this case. Please do a quick read of Factory design pattern.
Oct 23, 2017 at 1:32 comment added user286462 Let me edit my question
Oct 23, 2017 at 1:31 comment added user286462 I'm still learning, so for you to explain, is going take some time and go beyond the scope of the question. For example, If I wanted to keep weapon immutable, but have different types, so sword and gun, I could still keep the constructor private and use a static factory to return those types, correct?
Oct 22, 2017 at 23:56 comment added CodingYoshi @S.R. no that would not be better. You can leave it as is but if you are interested in why static code is harder to unit test then read the article I referred in my answer. Then try to unit test your code and you will run into obstacles and you will then clearly understand why static code is harder to test. It is really hard to explain this without a lengthy article or discussion. Also, if someone does not fully understand unit testing and mocking, then it further complicates the explanation. Is there a specific part you do not understand and perhaps I can try and explain that part?
Oct 22, 2017 at 23:48 comment added user286462 Would it then be better then to make the constructor public and use that for creating objects? In my case make the weapon constructor public?
Oct 22, 2017 at 23:33 history answered CodingYoshi CC BY-SA 3.0