DZone
Mobile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Mobile Zone > Mastering TDD

Mastering TDD

In this article, Ana Nogal presents a very helpful collection of TDD links and references.

Ana Nogal user avatar by
Ana Nogal
·
Jun. 15, 16 · Mobile Zone · Opinion
Like (2)
Save
Tweet
3.92K Views

Join the DZone community and get the full member experience.

Join For Free

Two weeks ago I went to Paul Stringer's course "Mastering TDD/BDD in iOS". After the two days, I was exhausted. During the course, we looked at all the theory and completed some exercises. Paul gave us lots of links and books to read and, quite frankly, I was feeling overwhelmed. I saw myself in front of the computer, with all those links to follow and read, and I didn't know what to do, so I laid back in my chair and closed my eyes and thought — What do I know about TDD?

Image title


Following the Rules

Well, I know that it has laws:

  • You must write a failing test before you write any production code.
  • You must not write more of a test than is sufficient to fail or fail to compile.
  • You must not write more production code than is sufficient to make the currently failing test pass.

I know I should follow the circle Red - Green - Refactoring:

  • Red - Create a failing test
  • Green - Write enough code to make the test pass
  • Refactor - Clean up your code and your tests (don't forget that your tests are code too)

This works well to enforce the three laws of TDD. And as Kent Beck said:

Make it work. Make it right. Make it fast.

If you want to know all about the cycles of TDD, here is an excellent article by Uncle Bob.

Going to Your Favorite School

And there are schools…well, not physical ones:

  • The Detroit/Chicago School or the Classicist approach
  • And the London School or the Mockist approach.

The first one uses real objects/classes and it tests the state of those objects. The second tests collaboration between objects and for that it uses mocks. You have this article by Sandro Mancuso and this other by Jonathan Rasmusson that can help you distinguish them better.

Knowing Your Friends

As an iOS developer, I tend to be more of a mockist since I drive my tests from the UI. And developing an app in Swift has some challenging aspects since we don't have a Mocking framework. We do it all "by hand," so, yes, knowing very well what kind of test double you need is a good thing. People tend to call them all mocks but as Martin Fowler said here:

Mocks aren't stubs

But if you still have doubts about test doubles, this excellent article by Uncle Bob will definitely shed a light on it (and I even found a version for Swift here). Magical!

Setting Your Priorities

Yes, that's a really important one: Use the Transformation Priority Premise to avoid big steps and to guide you into the generalization of your code. As Uncle Bob said:

...Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code.

Another good article is this one by Pedro Santos. Don't forget that during the refactor phase your design skills are put to test, as Sandro Mancuso said here:

TDD is not a design tool. It’s a software development workflow that prompts for code improvement in its lifecycle... The great thing about TDD is that it is constantly asking us “Hey, can you make your code better? See how hard testing this class is becoming? OK, you made it work. Here’s your green bar. Now make it better.”

Having Good Habits

TDD must be approached like a discipline. You must have good habits to stick with it. Here is the TDD good habits manifesto. This came up for the first time in SoCraTes UK ‘16 in a form of a session facilitated by Mani Sarkar and Pedro Santos, where they challenged us to add or remove practices to their original draft that you can see here.

Conclusion

Well, it seems that I have a minimum knowledge about TDD. I still need to practice a lot, and apply what I have learned when coding. Here are some books that you could read:

  • Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.
  • Refactoring: Improving the Design of Existing Code by Martin Fowler.
  • ATDD by Example: A Practical Guide to Acceptance Test-Driven Development by Markus Gärtner.
  • Test Driven Development by Kent Beck.
  • Working Effectively with Legacy Code by Michael Feathers.


This article was first published on my personal blog.

Testing Software development Test-driven development

Published at DZone with permission of Ana Nogal, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • MACH Architecture Explained
  • What's the Difference Between Static Class vs. Singleton Patterns in C#?
  • ETL/ELT on Kubernetes With Airbyte
  • Vaadin Apps as Native Executables Using Quarkus Native

Comments

Mobile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo