I always hear about how most Ruby developers have embraced testing. So today we’re going to test talk about the Ruby Testing Culture from a developers perspective with Jason Sweet from codewithJason.com. Jason has a bunch of courses and articles on his blog about ruby testing, and he shares his testing knowledge on a whole bunch of topics with us today. Check it out.

About Jason Swett

Jason Swett is a developer, trainer, author and former panelist on the Ruby Rogues podcast. Since putting his first website online in 1996, Jason has worked with organizations like AT&T, Lenovo, VMware, HP, Dow Jones, Deloitte, Kroger and the University of Chicago. He has taught programming in the United States, The Netherlands, Bulgaria, and Nigeria. Jason is also a co-organizer of the GRWebDev Meetup, the largest programming meetup in West Michigan. He lives in Sand Lake, Michigan with his wife and two kids.

Quotes & Insights from this Test Talk

• There’s this really great book I read years ago. I have it right in front of me right now. Actually, it’s called Working Effectively with Legacy Code by Michael Feathers and it discusses in the book what is legacy code. Because it’s it’s kind of a nebulous idea. People might have different definitions of it. The author of this book has a pretty interesting definition of legacy code. He simply defines it as code without tests and that was a different definition that I had kind of heard elsewhere or conceived of myself.
• The challenge with legacy code is that kind of inherent in the idea of legacy code is that it’s messy hard to work with code. And maybe the original maintainers are gone and so you have to. You have to maintain forward momentum still with feature development because the business still has requirements for features but you’re often afraid to touch it because if you touch anything you’re afraid things will fall apart. You can gain confidence by adding some tests so that you can you can have some assuredness that when you make a change you’re not going to break things if you have test coverage. But there’s kind of a catch 22 situation that is you can’t put tests on the code without changing it. But you don’t want to change that code without putting tests on it first. And so it’s kind of like how do you get past that catch 22?
• Usually, when I’m looking at a piece of code that I want to understand I’ll start by doing just that. I’ll take the entirety of the code and the idea is like I don’t want to change anything before I put some test coverage on it. The approach I use is TDD.
• there is some discernment that you just have to use some judgment as far as like what is the feature that I’m testing. It doesn’t make any sense. So that’s that’s just a judgment call part of it. But usually, you know if the code exists in the program it does something important. And so when you’re writing tests for it you can you can be pretty certain that that test has value. Not all of the parts of your application are equally they don’t get equal traffic and they don’t have equal importance. And so you’re going to have kind of a feel for which parts of your applications get more usage in which are like in the critical path of what the business needs. And that’s another heuristic you can use if you spend time testing things that only get used once every six months by like three people. That’s probably not huge value but if you’re testing something that tons of people use every single day. And clearly, that’s more valuable.
• If We write tests that are actually adding value that in the long run and even in the medium run it’s going to save us time because we’re going to deliver higher quality software. We’re going to have fewer bugs. It’s going to reduce our development cycle time because we don’t have to spend as much time on a manual QA. So please take the time to do that.
• Probably the number one thing that holds beginners back from getting tested is just that they don’t know where to start. So my advice to those people would be if you’re trying to get started writing tests for Ruby on Rails. I would actually advise you not to try to write tests for Ruby and Rails just write some test for only Ruby. So write something as simple as you possibly can put together a tiny really simple Ruby class Ruby files just a few lines. Write the simplest test you can possibly think of. And once you’ve done that add a little bit make it a little bit more complex once you’re comfortable with that. Keep going and I think you’ll find that once you’re over that hump continuing will be a lot easier.

Connect with Jason Swett

• Twitter: @JasonSwett
• Blog: codewithjason.com
• Company: codewithjason.com
• LinkedIn: jasonswett

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!