• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Five Lines of Code: Analogy of testing and car brakes

 
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christian,

You wrote:We can think about testing this way: automated testing is to software development what brakes are to cars. Cars don’t have brakes because we want to go slowly — they have brakes so we feel safe going fast. The same is true for software: automated tests make us feel safe going fast.


I find this analogy and line of reasoning problematic. I understand why you wrote this given its context but it seems to me that it's a flawed analogy and misleading at best.

A car has brakes so you can stop (or slow down) when you need to. In that way, yes, they keep us safe. However, "feeling safe" has very little to do with the utility and intent of putting brakes on cars. You may feel safe but if you don't pay attention to what's happening on the road around you, you can still crash and get hurt. Same thing goes with tests. You may have tests and feel safe but if you don't pay attention to what the tests are telling you about your code, then you're also likely to get in trouble. Likewise, a car without brakes is unsafe and so is refactoring without tests. There are few refactorings that are relatively safe to do without tests: rename being one of them.
 
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Junilu,

Can you make mistakes while refactoring? Sure. Can you make mistakes while coding? Yes. Testing is a business decision, not a technical requirement. If you work in an area where errors mean little to no damage you may not do any testing at all, if you work on a billion-dollar Mars rover then testing is not nearly sufficient to get the safety you need so you do proofs instead. As I mentioned elsewhere, I am not against automated tests by any means, I just think you can learn refactoring without having to learn (or know) automated testing.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the interest of full disclosure, I am a vocal proponent of TDD so I'm particularly biased against your apparent position or at least the approach you're taking in the book, trying to decouple refactoring from TDD and to some degree I suppose, testing.

That said, when I coach people on TDD, I take what I call the "Backwards Brain Bicycle" approach and go over refactoring before touching on tests or using tests to drive design and coding.
 
Christian Clausen
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
TDD (and automated testing) is one approach to get the level of quality you desire. There are others, like proving correctness. I don't think anyone of them is universally the appropriate one. It depends on the context. As a consultant, I coach teams on TDD if they find that is right for them. The purist in me wishes we could prove everything correct, and never have bugs again, but sometimes that is too expensive. Then I wish we could test everything, but sometimes that is too expensive too. Then I wish we would make completely fault-tolerant systems, but ... you get the rest.

No matter what level of quality you desire, and no matter the strategy to get it, the refactoring patterns and rules stay the same. This suggests to me that they can be learned separately.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:As I mentioned elsewhere, I am not against automated tests by any means, I just think you can learn refactoring without having to learn (or know) automated testing.


Don't get me wrong, I'm not trying to knock your book. I am, however, concerned that some of the issues I've pointed out could detract or even muddle a good message like "Five Lines of Code." This is one of those "context-free rules" that Andy Hunt wrote about in "Pragmatic Thinking & Learning: Refactor Your Wetware" that newbies rely on to get work done. For beginners, I think this actually would be a good guideline but eventually, they're going to need to understand the underlying principles and reasons why keeping methods down to Five Lines of Code is a good rule of thumb.

The issue I have with that particular passage is that it downplays the importance of tests. It's not about "feeling" safe, it's about being safe. Just as new drivers should be taught how to stop or slow down the car eventually (hopefully before they get on the open road), developers should learn to write tests to make any refactoring effort, no matter how small, safe.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:This suggests to me that they can be learned separately.


I don't disagree with you here. I just don't think it's responsible to separate tests from refactoring. I think refactoring without tests is risky at best and reckless if done as a "normal" practice. My fear is that people will (naively) take what you wrote in your book out of context and think that refactoring without tests is fine in real-world development situations, not just while learning how to do refactoring.
 
Christian Clausen
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

My fear is that people will (naively) take what you wrote in your book out of context and think that refactoring without tests is fine in real-world development situations, not just while learning how to do refactoring



Yes, I think this is correct. As much as I would like to I cannot prevent people from making poor decisions. Even with all the arguments for testing in Fowler's book, people still ignore it. Even when a large part of the industry preaches that it makes development both faster and safer, some people still ignore it.

The same btw. is true for pair and ensemble (mob) programming, which I also think many people would benefit greatly from, however I would never claim you can't learn refactoring without it. ;)

It's not about "feeling" safe, it's about being safe



It is about feeling safe. As Djikstra said, "tests can prove the presence of bugs, not the absence". You gain evidence through tests, however, to be safe you need formal machine-checkable proofs (or at least that is state of the art at present).
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:It is about feeling safe. As Djikstra said, "tests can prove the presence of bugs, not the absence".


That quote has nothing to do with feeling safe. Dijkstra ("i" before "j", by the way) wrote that in the context of proving correctness of a program. See http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF (bottom of page 7). In other words, you cannot prove/guarantee correctness of a program by citing any number of passing tests. You can only demonstrate incorrectness with at least ONE failing test. (Assuming all tests are valid, of course)

That quote is in fact a great reason to have tests when refactoring: because if you screw up somehow while refactoring, a failing test should immediately tell you about the problem and what exactly broke. If there are no tests to tell you that you just made a mistake in refactoring, you'll just keep plugging along toward the edge of that cliff where you wake up in the middle of the night to fix a problem in production.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:As much as I would like to I cannot prevent people from making poor decisions.


You could at least make it clear to people reading your book that testing isn't something you should gloss over when you're doing refactoring in the real world. I can get in line with learning about refactoring before really diving into testing. But as with learning how to make the car go, I think any instruction manual is incomplete without an equally thorough discussion of how to make the car stop and safety while driving. Please reconsider how you're writing about tests and their relationship to refactoring.
 
Christian Clausen
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The last paragraph of chapter 1 attempts to achieve exactly this:

Also note that because we focus only on learning refactoring, and we have a safe
environment, we can get away without automated tests — but this probably is not true for
real systems. We do so because it is much easier to learn automated testing and refactoring
separately.

 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:The last paragraph of chapter 1 attempts to achieve exactly this:


Glad to know. I've been task switching between watching the forum and reading through posts here and day job stuff so thanks for pointing that out.

I do wish you the best on your book. We need more developers to learn the importance of refactoring and how to do it properly and effectively (and testing, and TDD, and pairing/mobbing... )
 
Christian Clausen
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. In my workshops and through my consulting I take a much more holistic approach, and coach both testing, mobbing, Git, monitoring, architecture, you name it. But I am a firm believer in learning in isolation
 
Marshal
Posts: 70234
282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you mean by learning in isolation?

My, we are having some really interesting questions and answers about this book
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Christian is referring to learning refactoring by itself, not concurrently with other synergistic practices like automated unit testing or TDD.
 
Campbell Ritchie
Marshal
Posts: 70234
282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. I misunderstood that; I thought it meant learning without contact to other people.
 
    Bookmark Topic Watch Topic
  • New Topic