Interview with Jeff “Cheezy” Morgan

Hello everyone,

Today we have a surprise for you! Please meet Jeff Morgan, known as Cheezy (@chzy). Jeff gave us a nice full-blown interview about his new book “Cucumber & Cheese” and better testing practices, so… don’t let me take any more of your time—read on and get to know him!

1. Hi Jeff (Cheezy), thank you for taking the time to speak with us. You are a highly recognized figure in the Agile and ATDD worlds, but for those who don’t already know you, can you tell us a bit about yourself?

My passion is writing software and I’ve been doing it for nearly thirty years. A little over eight years ago I left my “corporate” job and started a company that later became LeanDog. Since that time I have been traveling around the United States and Canada helping software development teams get better at what they do by introducing practices from the Agile and Lean communities.

My drug is going to work with teams where the developers have no idea how to write clean code, the testers are performing only manual execution of scripts or random inspection, and the customer has no faith that the team can deliver a quality product. I love spending a few months with the team and seeing things turn around. I love seeing the developers become aware of craftsmanship and teaching them how to write high quality code by introducing TDD, pair programming, and principles of good design. I love seeing testers work closely with the developers and learn how to write code to automate their tests. I love seeing the customer’s faith in the team restored. I love to see high performing teams. This is what I do.

For the first half of my career as a coach I was very frustrated with the state of the testing profession; especially on the teams I worked with. They were almost always my constraint and they kept the team from reaching their full potential. Just as Kent Beck, Ron Jeffries and others in the development community raised the bar on what it means to be a professional developer, I decided to try to help do the same in the testing profession. I started introducing ATDD into the teams I worked with and started working with testers to help them learn how to write test automation using the same rigor I teach developers to write code. I also started pushing the envelop for what it means to collaborate on an Agile team. At first, a lot of my ideas were considered radical and extreme but over the years they have become more accepted.

2. When and how have you been acquainted with Ruby, and what do you like about it most of all?

I love all programming languages. I really enjoy digging into a language to determine what it has to offer. When given the chance, I like to select the language to use based on which one best solves the problem at hand.

With that background I discovered Ruby about six years ago. Rails was fairly new and a lot of people in the community were talking about it. I started studying the language and really liked what I saw. I really liked the simplicity of the language and at the same time the simple and powerful object model. I believed it would be easy to use metaprogramming to build higher DSLs for developers. That is the secret of rails.

A couple of years later I was working with testers trying to help them implement test automation. I began by looking at the existing tools and was shocked at how bad they were. Ruby seemed like a good solution. It allowed me to write code that built up high level DSLs that testers could use to build test suites. This eventually led to the development of several Ruby gems.

3. RoR developers might be very excited about your book, as we are in the RubyMine team. Can you tell us a bit about who this book is for?

My book is clearly about Cucumber. In the early days of Cucumber most people used the web steps that came with the gem or other gems like webrat. These tools typically yielded brittle test suites but they worked fine for small sites as it was easy to absorb the work necessary to keep the tests running. As the sites scaled and there was a need for more testing across different browsers we quickly discovered we had additional needs that were not covered by these gems.

My book attempts to cover several topics. First of all it provides a nice introduction to Ruby and Cucumber. It also introduces the reader to a host of additional gems that can be used with Cucumber to write robust flexible test suites. It also covers advanced topics like test data management and scaling up your tests. My book is becoming fairly popular in the testing community but I also believe that it has a lot of offer the developer community as well.

4. Why Cucumber? What advantages does this testing framework offer over others?

The greatest strength with Cucumber is its ability to express software behavior in natural language called gherkin. I use this feature to drive collaboration across the teams I coach. I usually start with the product owner or customer writing the specification for a story in gherkin. When the story is picked up by the developer for development we like to hold a very short discussion between the product owner, the developer, and the tester. This discussion should last no more than five to ten minutes and should review the gherkin to ensure we have a common understanding and to add any missing scenarios. We call this the 3 Amigos discussion. After the discussion the developer begins writing the code while the tester automates the scenarios. The developer will run the cucumber tests against their work frequently to inform them of their progress and learn what still remains. The tester sould also perform exploratory testing on the story as portions of it are completed. The story is only considered done when both the developer and tester are confident that the code is clean and defect free. This, of course, requires a lot of close colloboration between the developer and tester and cucumber delivers the specifications that are the focus of that collaboration. It has allowed us to remove the distinction between a “development” phase and a “testing” phase in our workflow. We simply have a development phase and testing is an integral part of it.

5. You have been developing Ruby gems for better testing. Can you tell us about your favorite ones?

That’s kind of like asking me to pick my favorite child. I love them all! My page-object gem is by far the most popular. It allows one to build an abstraction around a web page and isolate the remainder of your test suite from changes in those pages. Another pair of gems that have been getting a lot of recognition lately are brazenhead and gametel. They provide a rock solid testing platform for applications written for Android devices. Finally, data_magic is a gem that works closely with page-object to externalize and randomize the data used in your tests. This is an essential ingredient when you want to run your tests in parallel. When your tests run in parallel you lose control over the order in which they run. If you use the same tests data in multiple tests it is very easy for one tests to step on the data of the other and have random test failures.

6. And what testing tools, other than gems, can you recommend?

Index cards, a good development environment, and git. Seriouslly, I do not like heavy weight processes or tools. I like to keep it light and keep it simple.

7. It is an honor for us that RubyMine is referenced throughout the book. How long have you been using RubyMine? What do you like about it?

I am a long time emacs and command-line user dating back to the 1980s. I discovered RubyMine when it was first released. I was introducing Ruby as a platform for testing on the teams I was coaching and had already used and been happy with several other JetBrains tools – namely IntelliJ and ReSharper. I had a need for a fully integrated development environment and RubyMine delivered. It has been my go to tool ever since.

8. Are you missing any features in RubyMine?

I have had the opportunity to introduce many developers and testers to RubyMine and the one feature I hear mentioned the most is better completions when using classes that are constructed dynamically. I know this is a very difficult problem to solve and have been pleasently supprised with the continued progress made by the tool. Keep up the good work.

9. You’re coaching, doing a lot of talks all over the world, blogging and so on. What inspires you on a daily basis? Any books, blogs? Hobbies?

When I am on the road (which is about 90% of the time) I spend my evenings writing code. I also attend a lot of user groups in the towns I visit and enjoy discovering the locallly brewed beers. On the weekends I live a completely different life. I often camp with my family and enjoy fly fishing.

10. Thank you again for your time, Jeff, and we look forward to the final release of your book. Are there any upcoming events or topics that you would like to ‘plug’?

I would just like to invite the entire development community to push themselves to improve and study their craft and never give up on following their passions.

Develop with pleasure!
JetBrains RubyMine Team

This entry was posted in Better Code, Interview and tagged , , , . Bookmark the permalink.

4 Responses to Interview with Jeff “Cheezy” Morgan

  1. Alexander says:

    Wow, nice article, guys! Thanks Jeff for good book.

    Will someone take a look at one old bug, which still reproducing for both Win and Mac platforms with SSD: (please pay attention to the screenshots I’ve attached in comments!)

    Thank you! :)

  2. Pingback: JetBrains Interview | CheezyWorld

  3. Pingback: New Books for JetBrains Products | JetBrains Company Blog

  4. Very nice says:

    Very nice article. I recently attended session with cheezyjeff. Amazing energy! Inspires others to write neat code. Very well delivers concepts of ruby automation. He introduced me to Rubymine. Liking it so far

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>