@ricowork Maybe you ... By: danfromisrael. on 23 Jan 12, 17:03:23 @ricowork Maybe you should consider wrapping your class with some sort of LoggingDecorator where every mistake or? exception caught will be logged...
good? talk By: inzepinz. on 17 Dec 11, 21:54:05 good? talk
cool stuff .. nice ... By: kurtdegregorio. on 15 Nov 11, 01:36:01 cool stuff .. nice i like it =)) thanks for sharing =)) god? bless
@jessta314
Exactly ... By: Divinized. on 15 Jul 11, 05:14:51 @jessta314
Exactly what I was going to say. I know a group of people that prefer to dodge NPEs and end up confused when their application behaves oddly.
I may be naive for it, but I model my code after the Java APIs, they (mostly)? don't check for nulls, and it's good because most NPEs are caused by coding errors.
if I do? ... By: michaeldeng1981. on 27 Nov 10, 20:15:41 if I do? outsourcing project, or do a contract project, after delivery I'm done. why should I write unit test. what I care is integration testing and system testing.
This can explains why contract project has low maintainability in general.
How about loggers? ... By: ricowork. on 06 Oct 10, 22:11:54 How about loggers? Is it ok? to have in my class (like most do):
private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
Should the logger instance be passed in to?
11:55 it should? ... By: twistedbydsign99. on 29 Sep 10, 02:49:53 11:55 it should? definitely be an interface.
@MattCrypto The ... By: jessta314. on 15 Aug 10, 01:22:25 @MattCrypto The great thing about nulls is that? you instantly knows when the code under test has changed. The null pointer exception you get is a good signal.
@Titousensei I ... By: magwo. on 27 Jul 10, 00:17:14 @Titousensei I think it's mostly considered OK to have globally available loggers, due to one important detail - information flows only to such an object, not from them. You? will really never have code that inspects the recently entered log messages, and make decisions based on that data. What one object logs does not affect what other objects do.
If House does not ... By: 123drums123. on 20 Jun 10, 19:57:20 If House does not need Door then maybe you should have an alternative constructor for House object that does not have any arguments? OK, I know... in real application it always needs Door. But removing precondition because we "trust ourselves" is weak... Why do we even have any bugs in code? Why do we review the code others created? There's no place for such trust - everyone is just a human and sometimes makes mistakes? and that is why we need preconditions.
That's very ... By: Titousensei. on 02 Jun 10, 23:16:54 That's very interesting. But how do you deal with non-essential objects that are possibly needed throughout the code,? such as a Logger. Should I pass the global logger to each constructor so that each of their methods can log some messages? Or is it OK to use a singleton in this case?
I do not agree with ... By: Exarification. on 14 Mar 10, 20:22:17 I do not agree with the part 23:54 - 25:24. I? think the speaker is incorrect about wanting to test with a null parameter. Symantically speaking, if the house in the constructor states that it needs a door, a test and the rest of the code should always respect this requirement. If in some cases a house doesn't need a door (like in 'painthouse'), you could make the method static and pass the needed data as arguments or move the not always needed 'door' from the constructor to the specific method.
simply? good. By: jinqiangzhang. on 04 Dec 09, 01:10:34 simply? good.
I think you are ... By: kinkokonko. on 23 Aug 09, 05:13:40 I think you are inventing the point as this is not stated in the talk. The contention stil remains if you use new House(null) and this succeeds but house.getDoor().toString() fails, the code if more fragile. These are Google talks, Bloch =? chief architect, and I find these recomendations a bit our of sort. Given you also have Mockito for stubs I think Mitsuko is completely wrong and his ideas seem to come from laziness in developing the tests. test and real code should be of the same standard
The point is that ... By: miguel47. on 21 Aug 09, 17:29:21 The point is that there should be a separate HouseFactory that is responsible for wiring up the House object. The unit test for the HouseFactory makes? sure that Doors are included, the House itself doesn't perform the test.
Very insightful ... By: simarpaul84. on 23 Jul 09, 15:29:07 Very insightful talk that stresses the point that every module/method/constructor should ask for what it needs (dependencies) explicitly.? Global State, whether it is from a Singleton/Public Static Instance should be avoided.
It may be better than contex/aspect oriented progamming. Dependecies if passed argument(s), we would know what it needs at compile time; whether a dependency is missing in the context, would be known at run-time when context.get(..) gives null. :)
You are still ... By: kinkokonko. on 08 Mar 09, 11:40:06 You are still missing the point. He is meaning you should use null even for mandatory parameters , as you may be testing a method that doesnt use them. i.e you safe your selve a Mock. Even he doesnt mean this the whole part of the talk is meaningless
This is wrong and pure lazines. thank god? he doesnt design Space shuttles, i.e. it would be nice and painted , but when you hit start it would blow up as you havent asserted the flight control is in place.
If you call House( ... By: nieaka. on 04 Mar 09, 18:44:16 If you call House(null) then the provided argument is not an instance of 'Door' and will cause a fatal failure (and your null check will never be considered anyhow). Such a failure would indicate? a problem during the creation of door.
14:26 shows example usage of House, and the prior instantiation of Door. If you're passing null to House then instantiation of Door failed, so you already have problems.
Sure, if new House( ... By: nieaka. on 04 Mar 09, 18:41:42 Sure, if new House(null) is valid, you? are asserting that house does not require a door. If that's the case, then it is a perfectly valid test.
If that is not the case, then you should pass an object. In the proposed constructor at frame 13:27 you can see this:
House (Door d, Window w, Roof f)
You seem to be ... By: kinkokonko. on 21 Feb 09, 23:21:30 You seem to be missing the point. If it is invalid to have a house without a door you should never compromise the system stability based on laziness in the test. On responsibilitis. Sure you can test the door in isolation but your main responsibility? is to produce water tight code. I thinhk his ideas on 'null' are wrong, Null can be considered a friend, that is is you like friends that jump up a cut your throat in your sleep ;-) JSR 308 is a far more improved approach to null checks
Sorry, the 'talking ... By: nieaka. on 06 Feb 09, 17:48:18 Sorry, the 'talking down to? the audience' part is for the following post.
Hear his ideas ... By: nieaka. on 06 Feb 09, 17:34:28 Hear his ideas around 7:00-7:40. Giving the house a door in the test is really like mixing testing responsibilities, you will lose the ability to test and isolate house from door.
In regards to his 'talking down to the audience', I disagree. I feel like he boils these things down to a point where you can easily see the substance of the problem, which assists with understanding of these complex and abstract topics. This also? helps him cover more material in the short 30 minutes.
No, unit tests end ... By: codeslinger6502. on 27 Jan 09, 18:08:20 No, unit tests end up tightly coupled to the implementation anyway. The unit test is "sacrificial" code tightly coupled to the class under test so? it breaks first before production code does.
Your statement "the test AUTHOR is thinking too closely about the implementation" indicates a common misconception about object oriented programming: private object implementation doesn't mean the PROGRAMMER shouldn't know the implementation, it just means other CODE doesn't know the implementation.
(...)
In theory ( ... By: rhamph. on 03 Jan 09, 11:36:19 (...)
In theory (depending on the language, etc) you could have a signaling-dummy-factory that gets passed in an interface. It would then return an object that acts like null, but claims to support? the desired interface (or be the desired type).
Pragmatically, that's a bit bulky, and with a safe language you can usually just remove the null checks.
Latest comments made on this video:
By: danfromisrael. on 23 Jan 12, 17:03:23
@ricowork Maybe you should consider wrapping your class with some sort of LoggingDecorator where every mistake or? exception caught will be logged...
By: inzepinz. on 17 Dec 11, 21:54:05
good? talk
By: kurtdegregorio. on 15 Nov 11, 01:36:01
cool stuff .. nice i like it =)) thanks for sharing =)) god? bless
By: Divinized. on 15 Jul 11, 05:14:51
@jessta314 Exactly what I was going to say. I know a group of people that prefer to dodge NPEs and end up confused when their application behaves oddly. I may be naive for it, but I model my code after the Java APIs, they (mostly)? don't check for nulls, and it's good because most NPEs are caused by coding errors.
By: flowewritharoma. on 26 May 11, 13:11:32
cool?
By: michaeldeng1981. on 27 Nov 10, 20:15:41
if I do? outsourcing project, or do a contract project, after delivery I'm done. why should I write unit test. what I care is integration testing and system testing. This can explains why contract project has low maintainability in general.
By: ricowork. on 06 Oct 10, 22:11:54
How about loggers? Is it ok? to have in my class (like most do): private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class); Should the logger instance be passed in to?
By: twistedbydsign99. on 29 Sep 10, 02:49:53
11:55 it should? definitely be an interface.
By: jessta314. on 15 Aug 10, 01:22:25
@MattCrypto The great thing about nulls is that? you instantly knows when the code under test has changed. The null pointer exception you get is a good signal.
By: magwo. on 27 Jul 10, 00:17:14
@Titousensei I think it's mostly considered OK to have globally available loggers, due to one important detail - information flows only to such an object, not from them. You? will really never have code that inspects the recently entered log messages, and make decisions based on that data. What one object logs does not affect what other objects do.
By: 123drums123. on 20 Jun 10, 19:57:20
If House does not need Door then maybe you should have an alternative constructor for House object that does not have any arguments? OK, I know... in real application it always needs Door. But removing precondition because we "trust ourselves" is weak... Why do we even have any bugs in code? Why do we review the code others created? There's no place for such trust - everyone is just a human and sometimes makes mistakes? and that is why we need preconditions.
By: Titousensei. on 02 Jun 10, 23:16:54
That's very interesting. But how do you deal with non-essential objects that are possibly needed throughout the code,? such as a Logger. Should I pass the global logger to each constructor so that each of their methods can log some messages? Or is it OK to use a singleton in this case?
By: Exarification. on 14 Mar 10, 20:22:17
I do not agree with the part 23:54 - 25:24. I? think the speaker is incorrect about wanting to test with a null parameter. Symantically speaking, if the house in the constructor states that it needs a door, a test and the rest of the code should always respect this requirement. If in some cases a house doesn't need a door (like in 'painthouse'), you could make the method static and pass the needed data as arguments or move the not always needed 'door' from the constructor to the specific method.
By: jinqiangzhang. on 04 Dec 09, 01:10:34
simply? good.
By: kinkokonko. on 23 Aug 09, 05:13:40
I think you are inventing the point as this is not stated in the talk. The contention stil remains if you use new House(null) and this succeeds but house.getDoor().toString() fails, the code if more fragile. These are Google talks, Bloch =? chief architect, and I find these recomendations a bit our of sort. Given you also have Mockito for stubs I think Mitsuko is completely wrong and his ideas seem to come from laziness in developing the tests. test and real code should be of the same standard
By: miguel47. on 21 Aug 09, 17:29:21
The point is that there should be a separate HouseFactory that is responsible for wiring up the House object. The unit test for the HouseFactory makes? sure that Doors are included, the House itself doesn't perform the test.
By: simarpaul84. on 23 Jul 09, 15:29:07
Very insightful talk that stresses the point that every module/method/constructor should ask for what it needs (dependencies) explicitly.? Global State, whether it is from a Singleton/Public Static Instance should be avoided. It may be better than contex/aspect oriented progamming. Dependecies if passed argument(s), we would know what it needs at compile time; whether a dependency is missing in the context, would be known at run-time when context.get(..) gives null. :)
By: kinkokonko. on 08 Mar 09, 11:40:06
You are still missing the point. He is meaning you should use null even for mandatory parameters , as you may be testing a method that doesnt use them. i.e you safe your selve a Mock. Even he doesnt mean this the whole part of the talk is meaningless This is wrong and pure lazines. thank god? he doesnt design Space shuttles, i.e. it would be nice and painted , but when you hit start it would blow up as you havent asserted the flight control is in place.
By: nieaka. on 04 Mar 09, 18:44:16
If you call House(null) then the provided argument is not an instance of 'Door' and will cause a fatal failure (and your null check will never be considered anyhow). Such a failure would indicate? a problem during the creation of door. 14:26 shows example usage of House, and the prior instantiation of Door. If you're passing null to House then instantiation of Door failed, so you already have problems.
By: nieaka. on 04 Mar 09, 18:41:42
Sure, if new House(null) is valid, you? are asserting that house does not require a door. If that's the case, then it is a perfectly valid test. If that is not the case, then you should pass an object. In the proposed constructor at frame 13:27 you can see this: House (Door d, Window w, Roof f)
By: kinkokonko. on 21 Feb 09, 23:21:30
You seem to be missing the point. If it is invalid to have a house without a door you should never compromise the system stability based on laziness in the test. On responsibilitis. Sure you can test the door in isolation but your main responsibility? is to produce water tight code. I thinhk his ideas on 'null' are wrong, Null can be considered a friend, that is is you like friends that jump up a cut your throat in your sleep ;-) JSR 308 is a far more improved approach to null checks
By: nieaka. on 06 Feb 09, 17:48:18
Sorry, the 'talking down to? the audience' part is for the following post.
By: nieaka. on 06 Feb 09, 17:34:28
Hear his ideas around 7:00-7:40. Giving the house a door in the test is really like mixing testing responsibilities, you will lose the ability to test and isolate house from door. In regards to his 'talking down to the audience', I disagree. I feel like he boils these things down to a point where you can easily see the substance of the problem, which assists with understanding of these complex and abstract topics. This also? helps him cover more material in the short 30 minutes.
By: codeslinger6502. on 27 Jan 09, 18:08:20
No, unit tests end up tightly coupled to the implementation anyway. The unit test is "sacrificial" code tightly coupled to the class under test so? it breaks first before production code does. Your statement "the test AUTHOR is thinking too closely about the implementation" indicates a common misconception about object oriented programming: private object implementation doesn't mean the PROGRAMMER shouldn't know the implementation, it just means other CODE doesn't know the implementation.
By: rhamph. on 03 Jan 09, 11:36:19
(...) In theory (depending on the language, etc) you could have a signaling-dummy-factory that gets passed in an interface. It would then return an object that acts like null, but claims to support? the desired interface (or be the desired type). Pragmatically, that's a bit bulky, and with a safe language you can usually just remove the null checks.