The Clean Code Talks - Don't Look For Things!

[inzepinz]

good talk

[flowewritharoma]

cool

[michaeldeng1981]

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.

[ricowork]

How about loggers? Is it ok to have in my class (like most do):

private static final Logger LOGGER = LoggerFactory.getLogger(MyClas­s.class);

Should the logger instance be passed in to?

[danfromisrael]

@ricowork Maybe you should consider wrapping your class with some sort of LoggingDecorator where every mistake or exception caught will be logged...

[twistedbydsign99]

11:55 it should definitely be an interface.

[123drums123]

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.

[Titousensei]

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?

[magwo]

@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.

[Exarification]

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.

[jinqiangzhang]

simply good.

[simarpaul84]

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. :)

[kinkokonko]

This is a very good overview though I find views agaist precondition checks very contencious. Basically if you contend new House(null) is valid you are saying that the internal state of the House is ok without a Door. This may not be true. It is often better to ensure the consistent validity of an objects creation upfront rather than allow system fail 2 weeks after booting. I would advise Mocking to Door regardless of your test to only paint it. Donot increase the chances of bugs for ease.

[nieaka]

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.

[nieaka]

Sorry, the 'talking down to the audience' part is for the following post.

[kinkokonko]

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

[nieaka]

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)

[nieaka]

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.

[kinkokonko]

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.

[miguel47]

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.

[kinkokonko]

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

[vidmanx0]

Decent info but this guy really talks down to the audience which is irritating.

[MattCrypto]

Good video for the most part, although I'm not convinced about the "no null checking" advice. Passing nulls to show that something "doesn't matter" in that test shows that the test author is thinking too closely about the implementation of the class under test -- which could well change. Ideally, we should really code tests strictly to the contract declared by the class, and the use of nulls would seem to be a fragile shortcut in that light.

[DarkGoosey]

I agree. This is really an attack on Design By Contract when I feel that DBC/asserts and TDD/tests can work in symphony so well! DBC sets the hard contracts and TDD exercises the limits of those contracts (and even ensures violations are caught!)

[rhamph]

The problem is that the language uses null to mean "no object needed", whereas the speaker wants it to mean "signaling dummy". The type checking should exclude the former, but not the latter. It's a problem of the language that null exists for every type, rather than requiring a union (or similar polymorphic declaration.)

(blah length limit...)

[rhamph]

(...)

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.

[codeslinger6502]

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.

[jessta314]

@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.

[Divinized]

@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.

[lh32469]

Rather than allowing nulls in public constructors why not have another package private constructor that requires no params for Unit testing a particular Class?

[Su1c1dalProductions]

There is no point in first view comments and stuff like that....