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

Google Tech Talks
November 6, 2008

ABSTRACT

Clean Code Talk Series
Topic: Don't Look For Things!

Speaker: Misko Hevery

Category:

Science & Technology

Tags:

• google
• techtalks
• techtalk
• engedu
• talk
• talks
• googletechtalks
• education

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

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

[danfromisrael]

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

[inzepinz]

good talk

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

[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?

[twistedbydsign99]

11:55 it should definitely be an interface.

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

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