Agile in a Flash 45

FIRST Properties of Unit Tests – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #45)

> Fast

> Isolated

> Repeatable

> Self-verifying

> Timely

--

Fast. Tests should be really fast. If the entire unit test suite takes a minute, people will be reluctant to run it. Break dependencies to make tests profoundly fast and small.

Isolated. When a test fails, it should be for a single, obvious reason. A long, complex test may fail in many places for many reasons. Isolated tests can run alone or in a suite, in any order.

Repeatable. Tests can be run in a loop, without intervention. They will continue to fail or succeed until code is changed that breaks them. They do not leave the system in a state that will not allow them to run again.

Self-verifying. Unit tests are pass/fail. No interpretation is needed to determine success. If the test fails, it states why it failed.

Timely. Unit tests are written with the code, not after the code is completed. In TDD style, tests are written first. Your best results will always come from following the Red/Green/Refactor cycle.

Source: Brett Shuchert, TimOttinger

Avoid this: “I don’t have time to write tests because I am too busy debugging”

Another great blog article on this: http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

Agile in a Flash 44

A Rhythm for Success: The TDD Cycle – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #44)

> Red

> Green

> Refactor

--

Of the agile developer practices, TDD will change your coding approach most fundamentally. TDD is a rhythm that helps you continually keep steady, forward progress. In the TDD cycle, you produce enough test code to fail, produce enough code to make the test pass, and then refactor before writing the next microtest. Red and green are the colors shown by GUI test tools for failing and passing tests.

Red. Newbies commonly make the mistake of not watching tests fail first. The red is essential feedback that the tests are written correctly and recognized by the test runner.

Green. Making the test pass is the part that is obvious; the hard part is that you write only enough code to make the test pass. No more! By limiting the amount of coding, you force the tests to be more complete, you avoid the cost of an over-designed system, and you learn how to incrementally grow behavior.

Refactor. While the test is passing, before anyone can depend on its current implementation, clean it. Rename a test. Improve readability. Extract an interface or a class. Unlike the Green step, there are no limits on the amount of refactoring you can do per step, as long as the tests always pass. Refactoring is critical to survival; it is your main opportunity to ensure your system’s

design stays clean.

“All code is guilty until proven innocent”

Agile in a Flash 43

Really Meaningful Names – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #43)

> Are accurate

> Are purposeful

> Are pronounceable

> Begin well

> Are simple

> Depend on context

> Match name length to scope

--

Are accurate. Do not mislead the reader. Naming a user’s postal code birthDate might infuriate co-workers! Characters like O and l can fool readers into seeing the digits 0 and 1.

Are purposeful. Describe the intended use of a thing, not its origin or composition. Variable names like text and psz lack intention.

Are pronounceable. Pronounceable names are easily recognized and discussed. We want to talk about the code without sounding crazy.

Begin well . Leading differences stand out, but differences in the middle or end of names can be hard to spot.

Are simple. Long names are more descriptive but less distinct than short ones. Encoded prefixes and suffixes make differences between names subtle. Don’t try to cram too much meaning into a name.

Depend on context. The fully qualified name is the real name. The local name is just the nickname.

Relate name length to scope. Names in very small scope (short loops, closures) can be small. Names visible from many places must be extra descriptive.

See Clean Code [Mar08] for Tim’s exhaustive guide to naming.

"What's in a name? That which we call a rose

By any other name would smell as sweet." ~Juliet (Shakespeare)

Agile in a Flash 42

The Seven Code Virtues – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #42)

> Working, as opposed to incomplete

> Unique, as opposed to duplicated

> Simple, as opposed to complicated

> Clear, as opposed to puzzling

> Easy, as opposed to difficult

> Developed, as opposed to primitive

> Brief, as opposed to chatty

--

Working, as opposed to incomplete. A program that works is superior to one that might work later. TDD requires code to work early and often.

Unique, as opposed to duplicated. Many regression errors are the result of improvements to only one version of copied code. Eliminate duplication in TDD’s refactoring step.

Simple, as opposed to complicated. Simple code hides fewer bugs and tends to optimize well.

Clear, as opposed to puzzling. Code misunderstandings generate errors. Use Card 43, Really Meaningful Names, and simple structures to make such errors unlikely.

Easy, as opposed to difficult. Structure and organize code so that it is easy to use. Don’t hesitate to add convenience methods and classes.

Developed, as opposed to primitive. Prefer the clarification and encapsulation of abstract data types to built-in variable types. Primitive obsession muddles the code and can create maintenance nightmares.

Brief, as opposed to chatty. Code should be brief but never cryptic. All other virtues still observed, less code is always better than more.

"Complicated code is infinitely more difficult to maintain and debug than simple code.” 

Agile in a Flash 41

Build Superior Systems with Simple Design – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #41)

> All tests must pass

> No code is duplicated

> Code is self-explanatory

> No superfluous parts exist

--

As far as a prescriptive set of design principles go, these four rules(11) of simple design, listed in order of importance, are the simplest thing that might possibly work.

> Code must work and be demonstrated by passing tests. A great paper model of a design is useless if the software doesn’t work. Use TDD so that you know the code is working at all times.

> Removing duplication is the next most important design activity, because it directly lowers the cost of system maintenance and drives you toward an appropriate level of abstraction.

> Contrary to popular belief, it’s almost always possible to create code that others can understand and maintain—particularly if your TDD-created tests clearly document intended behavior. Maintenance costs rise dramatically with unclear code.

> Finally, YAGNI (You Aren’t Going To Need It) tells us to remove all superfluous features and complexity—anything not needed at this precise moment.

11. Extreme Programming Explained, First Edition

"A simple design always takes less time to finish than a complex one."

- extremeprogramming.org

"A man should look for what is, and not for what he thinks should be."

Albert Einstein

Agile in a Flash 40

Eight Crucial Practices of Agile Programmers – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #40)

> Continuous integration (CI)

> Test-Driven Development (TDD)

> Constant design improvement

> Coding standard

> Collective code ownership

> Simple design

> System metaphor

> Pair programming

--

Agile programmers use these eight practices that derive from Extreme Programming (see Extreme Programming Explained, First Edition) to improve their software development practice. The practices can work individually but have a profound synergy when used together.

A coding standard (see Card 35, Coding Standards) is foundational for working as a team that collectively owns the code. Continuous integration ensures the system is always in working order. You know the system works because it has been built by pairs of programmers reviewing the other person’s work and using TDD (plus automated acceptance tests) to verify that it works. You know the system has a quality design, because the programmers use TDD to continually improve the design (refactor) using simple design concepts.

You communicate these system ideas with your whole team—which includes the business and other nontechnical folks—through use of a metaphor. A metaphor is a shared system vision and language that simplifies decision making and reduces the need for deep-code spelunking. The shopping cart is a common metaphor; you talk about “carts, items, and checkout.” You might end up with what’s

known as the naïve metaphor: “This is a purchasing system, with orders, inventory items, and submissions.” Boring but effective enough!

"Don't practice until you get it right. Practice until you can't get it wrong.” - Unknown

Agile in a Flash 39

How to Stay Valuable – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #39)

> Stay positive

> Stay engaged

> Stay professional

--

Be valuable to your employer, whether times are good or bad and whether you’re talking about your current employer or your next one.

Stay positive. A positive attitude is crucial to building goodwill, inspiring others, and having fun. Staying positive when things are difficult is not just good citizenship; it is leadership.

Stay engaged. You are not effective when you are not participating in the work of the team. Focusing every day is hard, so use pair programming and perhaps the Pomodoro Technique (see Pomodoro Technique Illustrated) to help keep your head in the game.

Stay professional. As long as you are on the job, you are an ambassador of your profession. Learn and model those attitudes, skills, and techniques that improve the quality of work for the team (including customers and managers). As much as possible, be helpful and diligent in your work. Remember

that you are building a reputation, and make it a good one.

"Leadership is lifting a person’s vision to high sights, the raising of a person’s performance to a higher standard, the building of a personality beyond its normal limitations." —Peter Drucker