[00:00:00] (Music) SY: Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron and today we're talking about testing. (Music) The first time I heard about testing I thought why on Earth so I need to test the code I wrote? I can see what it does. It's right there. But I kept an open mind, forced myself to learn testing and pretty quickly became a believer.

[00:00:33] JN: Hi, My name is Jonas Nicklas. I'm a freelance developer from Gothenburg in Sweden.

[00:00:38] SY: Jonas wrote one of the testing frameworks that I use all the time. It's called Capybara. And today, he gives us an amazing beginner-friendly intro to the world of testing: what it is, what it looks like and how to get started after this.

[00:00:56] Flatiron School teaches you how to code from anywhere. They've got an awesome community of career-changers and a number of different options for you to pick from to become a software engineer. They've got full-time in-person courses, self-directed introductory courses and a remote online web developer program. They even have a free 75-hour online prep course where you can learn Javascript, Ruby and do some interview prep. Go to flatironschool.com/podcast to learn more. That's flatironschool.com/podcast. Link is in your show notes.

[00:01:30] One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about and share that passion with the world. And Hover can help you with the first step of sharing your passion with the world: getting your domain name. They've got a really beautiful and easy-to-use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free WHOIS privacy, so your personal information is safe, too. To get started, go over to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes. 

[00:02:18] DigitalOcean provides the easiest cloud platform to deploy, manage and scale applications of any size. They remove infrastructure friction and provide predictability so you can spend more time building what you love. Try DigitalOcean for free by going to do.co/codenewbie and get $100 of infrastructure (Music) credit. Link is in your show notes.

[00:02:43] SY: Ok, so before we get into Capybara specifically, let's take a step back and talk about just the world of testing. When it comes to software, product development, what is testing?

[00:02:55] JN: The idea of testing is that instead of verifying that your software does what you intended to do by hand, you actually write code to verify that the software does what it's supposed to. 

[00:03:12] SY: So why do I need to do that? I mean if I told the software to do something, then shouldn't it just do it?  

[00:03:18] JN: You might think so. (Laughing) So the idea is that software usually has a lot of complicated interdependent behavior. So you don't only have one functionality, you have a lot of functionality. And if you change something in one part of the system, you might be affecting some other part of the system without even realizing it. So instead of forcing you to go through your entire application and testing every single thing that could possibly go wrong, you let the computer do that instead. And the computer's very good at executing a lot of things very fast and checking things very fast as opposed to yourself as a human where it would take you much, much longer to go through the entire application and to check everything. 

[00:04:08] SY: Yeah, that's a really great way to explain that because it really is the interdependence where you really start to see the benefits of testing because if you're starting, you know, from a completely greenfield project, you only have one little piece of code. Testing that one little piece of code might feel kinda silly, (Laughing) you know? 

[00:04:27] JN: Right. 

[00:04:27] SY: But the more you code and the more stuff you have, the harder it is to just remember what you wrote to begin with. 

[00:04:34] JN: Exactly. And the—in the beginning verifying everything manually is easy because you can, you have a somewhat solid grasp about all the functionality that in, is in, in your system and checking that everything still works as intended is pretty fast. As your software grows, that becomes more and more challenging. 

[00:04:53] SY: So, ok, if I decide I believe in testing. I wanna try it out. I wanna figure out how to do that so I'm not manually testing all these little pieces in my code, where do I start in the world of testing?

[00:05:07] JN: So most programming languages these days ship with some kind of testing library in their standard distribution. So if you have a programming language that you're working in most likely you already have some kind of testing framework accessible. You can go even simpler than that and just think of any code that you write which checks the behavior of your software is testing. You can just write a program like you would usually write a program which runs your other program. You can even simplify it further, but I think where most people start is with the built-in testing library that is built into their programming language. 

[00:05:50] SY: So if I were to test a really simple piece of code—let's just start with "Hello, World!"

[00:05:58] JN: Right. 

[00:05:58] SY: Right? If I have a really simple piece of code that says, you know, print "Hello, World!" to the screen. If I were gonna write a test for that, what might that look like? 

[00:06:08] JN: So tests usually contain assertions. And an assertion is basically a, a line of code which says I expect this thing to be in a certain way. And if it's not in this way, then the test will fail. And if the assertion is correct, it will pass. So in, in the case of a "Hello, World!" program, for example, you could be checking that, assert that the text "Hello, World!" was written to stand it out or to your display. And that would be the way you would check that that the program behaves as you intend. 

[00:06:49] SY: And so once I write that test, that assertion, what do I do with that test? 

[00:06:55] JN: Usually test frameworks have a test runner, which is a command line utility that you can use to run the test. And this will run through all the tests that you've written. It will execute the code in your test and it will check that the behavior of your program conforms to the test that, that you've written. And then it will give you some output that these tests passed and these tests failed. 

[00:07:25] SY: Ok, so I have my code. My code says, you know, put "Hello, World!" And now I have my test, which is my assertion, that says, you know, does this piece of code actually print "Hello, World!" out to the screen? And then I have my, my runner, the thing that actually runs that test. When would I run the actual test? How often do I—do I need to do that every time I use my app? Or like what—is there, is there a schedule, a routine to how often I should be running these tests? 

[00:07:57] JN: So I think it depends a lot on your, let's say on your habits. Personally, I run the tests that are associated with the piece of code that I'm working on right now. So parts of my tests I know affect the, the code that I'm, I'm working on right now. And these will be the tests that I run as I make changes. So I make some change to my code, and then I run my tests and check whether everything still works. If I'm at a point where I'm satisfied with my changes, and let's say I want to make a commit, that's when I might run the entire test suite or also I might have some server set up which runs the entire test suite for me. 

[00:08:41] SY: Yeah, that makes a lot of sense 'cause going back to the, the point of testing in the first place, you know, you wanna make sure that when you do something, you add something, you change something that everything still works. So whenever you make a change you should run the test and see if things still work. 

[00:08:57] JN: Exactly. Yeah. 

[00:08:59] SY: When do I write the test? Do I write it in anticipation of the code? Do I write it after the code is written? Does it matter when the test actually gets written? 

[00:09:12] JN: A lot of people feel very strongly that it does matter. So there's this entire movement called test-driven development which puts a whole lot of emphasis on the idea of writing the test first. So that would be that you write sort of the specification for how you expect your code to work. And then you switch to writing the actual implementation of that specification. And you see does my implementation actually match the specification? This is for most people a really good starting point. At the end of the day, I tend to be a little more flexible where maybe I'm doing something like 80% of the time I write the test first and 20% of the time I write the code first. It comes a little bit with experience in my opinion that you kind of get a feel for which is easier in a given circumstance. So starting out from writing the test first I think is a good starting point. 

[00:10:16] SY: Ok, so why? Why is it favorable at least in the beginning to write the test first? What are the, the benefits of that? 

[00:10:24] JN: For one, it makes it easier to maintain discipline I think. If you write the code first, then you have that satisfaction of being done kind of. (Laughing) And then you might be like... 

[00:10:36] SY: That's true. 

[00:10:38] JN: ...maybe I don't really need to write the test. (Laughing) So it, it sort of forces you into a discipline of I'm always writing tests. And I think the other reason is that writing the specification first gives you sort of more constraints. It makes you write less code because you're only writing the code which fulfills the specification. So it kind of forces you not to get too far off track and to only focus on the, the thing that you're implementing right now. I think it's really easy when you're writing code to get sidetracked and to think too much about the bigger picture and that “oh I really need to build up this thing and I need to build up this thing." I'm a really big believer in, in trying to keep things as simple as possible until you get to a point where it can't be simple anymore. And I think that this test first mentality really forces you into this, this mindset of ok I'm specifying a really small amount of functionality, and then I'm implementing only that tiny bit of specification as opposed to thinking too big. 

[00:11:58] SY: Yeah, and especially for a newbie, one of the things that I loved about test-driven development specifically is by having to write the test first, it gave me a process because without it I'm thinking like oh, I guess I can start—I guess I could start with the model. Maybe the control—it is specifically for a Rails app. Do I write the view? You know, I can—I feel like I have so many different starting points…

[00:12:22] JN: Right. 

[00:12:22] SY: ...and so many options, but when you have to write a test first, it's like ok, I need to focus on this working this way. I have a story, like I have a beginning. I have a middle. I have an end. And it gives me a very clear and focused starting point, which I found really valuable when I was new and just felt overwhelmed a lot of the time. 

[00:12:41] JN: Right. I think that's a really, really powerful thing about test-driven development that you have this—when you're running the test after you finish written it, obviously it will fail for some reason because you're, you haven't actually implemented it yet. And you can let that failure message guide you...

[00:13:02] SY: Yeah.

[00:13:02] JN: ...sort of through your journey of what you're supposed to do next. Is it getting some kind of error about—let's say in a Rails app I've written a test. And the beginning it might say that "not found" because there's no route implemented yet. That guides me towards "ok, I need to implement a route." And now I have a path forward. I sort of have guide rails all the time kind of pushing me in a certain direction. 

[00:13:34] SY: Yep. And it also—especially for newbies—it helps change how you feel about error messages because in the beginning, when you're not used to that much failure, it could feel terrifying. Like I remember the first error message I got I thought, "oh my God. I broke my computer." (Laughing) You know? It's, it's such a—and it's in red and it looks scary. And it, you know, looks really angry at you. So it could be just, just really shocking at first, but when you do test-driven development, you look forward to the error messages. You go, "oh, ok. Cool. Now I know what to do. Oh, there's another one. Great, I could do this, too." You know? 

[00:14:06] JN: Right, yeah. 

[00:14:07] SY: It becomes like a, a little tutorial almost, you know? Just kind of...

[00:14:10] JN: Yep. 

[00:14:11] SY: ...guiding you to the next step. So it makes you more comfortable with errors as...

[00:14:15] JN: Right. 

[00:14:16] SY: ...your friends and as something that are actually helpful. 

[00:14:18] JN: I think that's a good point about programming in general that error messages are your friend. That you should try to understand them as much as possible and try—what, what do the different parts about this error message mean and, and really spend time reading it. Because it gives you a lot of information I think that's, that's really valuable, especially for, for beginner programmers. 

[00:14:41] SY: Ok. So let's talk about different types of tests, 'cause not all tests are equal or have the same purpose. What are the different types of tests that I can implement? 

[00:14:55] JN: So usually we separate different types of tests by what it is we are testing and how it is we are testing it. If we look at the "how" first, the main divide is between unit tests and integration tests. And the idea of a unit test is that we are testing just one piece of code in isolation. So in Ruby, for example, you might think that you take one class. That's the piece of code that you're testing in isolation where it might be different in other programming languages, but usually, it's like whatever you can fit into one file. So we are taking this, this unit of code and we are trying to isolate it from the, the rest of the code. Whereas with an integration test, I am testing a larger slice of the system. With an integration test, I'm testing multiple pieces of my, my software working together. And I might be testing how do they interact? 

[00:16:05] SY: So if we think about our "Hello, World!" testing example thing that we talked about earlier, if I wrote a method and said, you know, the method is called "say hello world." And I wanted to make sure that that method actually did print "Hello, World!" out to the screen. It sounds like based on the difference between a unit test and an integration test that testing that method is probably a unit test. 

[00:16:33] JN: Yes, but the divide between the two can be sort of fuzzy a little bit. So in our case, we do have another part of our software that this "say hello" method is interacting with. And that's our screen. So it's putting this "Hello, World!" somewhere. And we could reason that it's an integration test because we're integrating with this other part of our...

[00:17:03] SY: Yeah. 

[00:17:03] JN: ...software: the screen. Right? But the screen is so fundamental that we still see this as a unit test. So the line becomes a bit, a bit fuzzy if that makes sense. 

[00:17:16] SY: Yeah, and that actually brings up another point which is when do you stop testing because you know if we, if we go down that road, then I can say well my keyboard is interacting with my fingers...

[00:17:27] JN: Right. 

[00:17:27] SY: ...is interact—you know what I mean? Like we could just...

[00:17:29] JN: Yeah. 

[00:17:29] SY: ...kind of keep going forever. So when it comes to figuring out if I had to focus on what to test, what is it that I'm testing? Am I testing all the pieces of every system ever?Am I testing the things that I particularly wrote myself? You know, what—where is the line? 

[00:17:48] JN: Testing is about confidence. It's about giving you confidence that the software works as intended. So the correct and maybe a bit hand-wavy answer is you need to write enough tests that you get that confidence but no more. The more tests that you have, the harder things become to change. You're trying to find that balance of enough. 

[00:18:17] SY: That's a really good point. Yeah. And so in the example of "Hello, World!" I might say that, you know, if I'm using in that method—the method that I wrote—if I'm using—if it sets puts and then "Hello, World!" I hope I would feel confident that the puts method works because that's not me, right? I didn't write that. 

[00:18:35] JN: Yeah. 

[00:18:35] SY: Someone else wrote that. It probably has its...

[00:18:37] JN: Yeah. 

[00:18:37] SY: ...its own test, its own light, you know, its own thing. But I wrote my own method of "say hello world." So I don't really maybe have a lot of confidence in my method, but I probably have a lot of confidence in the puts method. So that...

[00:18:50] JN: Right. 

[00:18:50] SY: ...might be a good (Music) delineation between what I should be testing and what I can, I can kind of let go. 

[00:18:56] JN: At some point you need to trust that other parts of the system work as intended. 

[00:19:01] SY: Coming up next, we hear more about Capybara, the testing framework Jonas created. He shares how he wrote it, what the response was and what it's been like to build this really popular open source tool. After this. 

[00:19:17] When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick east-to-use interface. They've got awesome domain names to pick from and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes.

[00:19:49] You want to get serious about learning to code, but where do you start? Flatiron School's got the perfect thing. They're offering their free 75-hour online prep course, where you dig into Javascript, Ruby and more. If you're not sure where to start, start there. And when you're done, you can keep learning with their self-directed introductory courses, remote online web developer program or full-time in-person courses. Whatever your schedule, they've got options to help you reach your coding goals. To learn more, go to flatironschool.com/podcast. That's flatironschool.com/podcast. Link is in your show notes.

[00:20:26] DigitalOcean is the easiest way to deploy, manage and scale your application. Everything about it was built with simplicity at the forefront. Setting, deploying, even billing. Their support is amazing. They've got hundreds of detailed documentation and tutorials, so if it's your first time deploying an app, they've got great tools and community to make it nice and easy. Try DigitalOcean for free by going to do.co/codenewbie and get $100 of infrastructure (Music) credit. Link is in your show notes.

[00:20:58] SY: Ok, so let's move on to Capybara. Where does that fit into the testing world? What is it? 

[00:21:04] JN: Capybara is a testing library which tests code from a very high level. It tests web application by interacting with them how the regular user would. So if you think about how you use a website, that is how Capybara tests your software. So it's from a very sort of high level perspective as opposed to we were talking before about unit and integration tests. Capybara is, is testing at the most integrated level. 

[00:21:41] SY: Ok, so for a web app, what does that actually look like? What are some things that I might write using Capybara? 

[00:21:51] JN: So we have methods with very natural-sounding names in my opinion. Things like "visit" or "click link" or "fill in," which basically do what you kind of expect them to do. 

[00:22:08] SY: And so if I am trying to test, you know, I have a website, the CodeNewbie website. I can add new podcast episodes to that. If I wanted to write out a, a new piece of functionality that lets me edit a podcast episode, how might I use Capybara or even just testing in general to do that? 

[00:22:31] JN: The methodology that I usually follow when I, when I write tests with Capybara is that I start off with writing that high-level test of editing a podcast episode might be that I visit the CodeNewbie website and I login by clicking the login button and then filling in the email and password fields, and then I press the login button. And then I go to the podcast list. I pick one. I press the edit button. And I do on that page whatever I edit action I want to perform. So I would literally write that down as a Capybara test. And then I would use that as we talked about before to guide me in my implementation. So I see that at some point it's going to—maybe we haven't implemented the edit podcast functionality yet, so at that point, it's going to tell me that "hey, there's no edit button. I can't click that because it, it doesn't exist yet on the page." And then I know that ok, I need to add an edit button. And maybe I add that button, but it doesn't go anywhere yet. So then the next error message I get is telling me that "hey, the error button is going to a page which doesn't exist." And then I know that ok, maybe I need to build a route. Maybe I need to add a controller. And at that point, I also realize that ok, I'm adding a model. I'm adding a controller. That's functionality in it of itself. And maybe I want to write more focused tests for these particular pieces of code. So maybe I want to take just that controller in isolation, or just that model in isolation and start writing unit tests for those. So we have sort of a, a big cycle in Capybara where we're stepping through. And then we can also have the smaller cycle when in that writing unit tests and trying to make that advance the big Capybara cycle a little more if that makes sense.  

[00:24:29] SY: So why did you create Capybara? Where did that idea come from? 

[00:24:32] JN: It's actually not my idea. Capybara is pretty much a rewrite of an existing library, which was called Webrat, which existed before it. The difference between Capybara and Webrat is that at the time—this was back in I think 2008 or nine or something like that—and web applications weren't really that Javascript heavy. Most web applications were just serving HTML over HTTP. Webrat had very little support for executing Javascript. We were kind of stuck in a position where the web was moving towards more and more Javascript but our testing libraries weren't really keeping pace with that. I basically did a, a rewrite with, with slight changes to Webrat to make that API support Javascript-heavy applications. 

[00:25:31] SY: Why do you think that Capybara is needed or is important? Is it actually allowing us to do things with testing that we can't do? Is it making it easier? What do you feel like is the biggest value to this framework? 

[00:25:45] JN: To me, the biggest value of Capybara is that if you think from a business perspective the thing that you care the most about is that the users are getting the experience that they expect. If you are a, a business person and you think about what do I feel is most important? To me, the answer is the user experience. If a user does something, it should work as it's supposed to. And Capybara is really testing from that level. You can be sort of down in the weeds of your, of your small part of the application, but that doesn't check that the overall functionality is as it's supposed to.  

[00:26:28] SY: What was it like to actually rewrite it? What was that process like? How long did it take? 

[00:26:34] JN: It depends on when you would consider it done. (Laughing) Kind of.

[00:26:38] SY: Yeah. 

[00:26:39] JN: Actually, I, I had something reasonably usable fairly quickly. I think that took me a couple of weeks. 

[00:26:48] SY: Oh wow. Wow, that's great. 

[00:26:50] JN: It went pretty fast to get to a point where we could start using it to test our software. But then obviously Capybara at this point is a software project which is I think eight or nine years old, but still there are changes being made to Capybara continuously even at this point eight or nine years later. So you could say either it took me a couple of weeks or it took me nine years depending on, (Laughing) depending on your point of view. 

[00:27:20] SY: Yeah. What was the response like to Capybara? Because you mentioned, you know, it, it already had a predecessor...

[00:27:27] JN: Right. 

[00:27:27] SY: ...I guess. You know, there was already a version that people...

[00:27:29] JN: Yeah. 

[00:27:29] SY: ...were, were using. So what was the response to the rewrite? 

[00:27:33] JN: Really positive actually, which I thought was, was really great. It seemed like the, the project sort of struck a nerve so even when it was a really young project, I had people who were well known in the community at the time taking an interest and trying it out and, and also sort of pushing for its adoption, which was really crazy to me at the time because I, I really had no experience with writing open source software, so, so it...

[00:28:06] SY: Wow. 

[00:28:06] JN: It freaked me out a little bit. (Laughing) But it was really great. I got a lot of support from the community, and I also got other contributions to it really, really quickly, which was a challenge in it of itself, but also very rewarding. So that was actually really, really enjoyable to see. 

[00:28:26] SY: So I imagine when something gets really popular, that also means there are a lot of people who have a lot of opinions and feelings about... 

[00:28:35] JN: Right. 

[00:28:35] SY: ...what you did and how you did it. 

[00:28:38] JN: Yeah. 

[00:28:38] SY: Did you get any negative feedback? Anything that made you upset or feel differently or maybe a little nervous? 

[00:28:46] JN: Open source soft, software maintainership is a lot about dealing with people and not all the people you deal with are necessarily respectful and nice. So sometimes that can be challenging for you to sort of keep calm and keep a good level of discourse even if, if maybe the people you are interacting with don't treat you with the same respect that you would like to be treated with. In a sense, it's a good experience to, to work in as a maintainer for, for an open source project because you get to experience sort of what the other side is like. 

[00:29:31] SY: Any regrets on doing Capybara or creating it in any particular way? Anything you wish you'd done differently? 

[00:29:39] JN: There are certainly some minor things that I, I think about the way that it's written or the API that I would like to have done differently or changed, but I still really like the project and I'm really happy that I, I wrote it and that it's been received so well. So no regrets from, from that perspective. 

[00:30:01] SY: Nice. So for all the code newbies listening who hopefully are interested in, in looking into testing, maybe trying it out for the first time, what advice do you have for them? 

[00:30:13] JN: When I first heard the word "testing" in relation to software, I thought it sounded kind of boring. (Laughing) And I just want to get across that it's really not boring at all. It's, it's really—writing well-tested code is really a lot more satisfying than writing untested code. 

[00:30:36] SY: So true. 

[00:30:37] JN: It's just a nicer feeling in a way to write software this way. For me, when, when I started doing that, I really, I really fell in love with this way of working. I really do think that it produces vastly, vastly better software than writing without tests. That, to me, is, is why testing is so great and why I would encourage everyone to start learning about testing from, from the very beginning. To me, it's really fundamental to software development. 

[00:31:10] SY: Yeah, it's incredibly empowering, you know, being able to... 

[00:31:14] JN: Right. Yes. 

[00:31:15] SY: Yeah. To write new features and new stuff without freaking out in the back of your mind of oh man, what, what is this gonna do to the rest of my codebase? You know, just having that safety net, you know? That thing that says you know there's someone, there someone is gonna have my back, you know, and make sure I don't do anything too detrimental. You know, it's not a complete safety net. It doesn't catch everything, but it definitely helps with your confidence for sure

[00:31:36] JN: Right. 

[00:31:37] SY: All right. So let's switch gears a bit and talk about languages in general, specifically Ruby. I think it was two years ago, maybe three years ago when Justin Searls gave a really great talk at—I think it was RubyConf, which was kind of like a, almost like a rallying call to Rubyists and Ruby developers and basically him saying, you know, Ruby might be getting a little less popular nowadays because its maturing and it's actually really stable and just doesn't really need a lot of new stuff nowadays. You know, I think to the rest of the world something like that sounds great and safe and secure, but for developers a lot of times that means it's not as interesting, and it's not as fun to play with. And so I wanted to kinda just get your thoughts on that. Do you feel like Ruby maturing or just, in general, a programming language being a little more mature, do you see that as a good thing? A bad thing? Something in between? 

[00:32:36] JN: Both I would say. It's a bad thing from the perspective that you don't have that youthful enthusiasm at the same sort of level. When I started working with, with Ruby, it was really cutting edge and very few people were, were using it for critical software. Now it's become very mature and a lot of big companies are using Ruby. It's a really double-edged sword because I think entering the world of software development with Ruby and Ruby on Rails now is actually better than it was then because there is a lot of work. There are a lot of applications that need to be maintained. There are actually a lot of new applications being written in, in Ruby and Rails today. If you're looking at this from a job market point of view, entering in, into a language that is mature is actually better because there's more work. And today, I think that is much less of an up, uphill battle because you, you're looking at a mature, established ecosystem. 

[00:33:43] SY: It's almost like there are—in a, in a business, in a product team, there's kind of like two types of people. There's the person who wants to play it safe, you know, and wants to make sure that whatever language they pick, whatever framework they pick is gonna be around and gonna be reliable. But then there are the other, the other group—usually the developers maybe—who wanna try something new, and they get really excited about the next language, the next framework, and might, you know, advocate for something that maybe isn't quite ready. So it sounds like when we're talking about the job market in general, the more stable language wins. Is that fair? 

[00:34:19] JN: Yes. I would think so. I think there, there is—it's easier to find work if you go for that market. But I think it depends a lot on you as a person. What do you want to do? Where do you want to position yourself? Do you want to be in the stable place where you're pretty much guaranteed to find work? Or do you want to be on the cutting edge? And I think it's very important that there's nothing negative or wrong about choosing that safe path. It's just a matter of figuring out which is where you want to be? 

[00:34:56] SY: So as a Ruby developer, though, do you feel like the language being more mature and more safe, do you think that means that it is going to decline over time? Or do you feel like we are maybe just getting to the good part where we'll have even more opportunities and such? 

[00:35:19] JN: I do worry a little bit sometimes. I, I think what worries me the most is that to me, Ruby came with a lot of lessons, with a lot of lessons for the programming community in general about how to work with software in a very efficient way. I feel like that lesson has maybe gotten a bit lost in other language communities. If I look at something like Node, I really feel like they could use a little bit of that, of this idea of convention over configuration and of having things work nicely out of the box instead of spending a lot of time setting up your particular set up for your particular application when you could really use something that is shared by everyone. And I think that a lot of other language ecosystems could really benefit from that lesson. So I don't think Ruby is necessarily declining now, but I would hope that other languages that are looking to take parts of that market would maybe look a bit at what made Ruby and Rails succeed and, and why they became so popular and try to incorporate those lessons a little more into their ecosystems. 

[00:36:45] SY: So if I'm a new programmer, I'm trying to figure out what my first programming language should be, where I should invest my future in, really, how should I go about that? Does it make sense to focus on things that are a little bit new and up and coming? Does it make sense to focus on the ones that are more mature and more stable? Or how do you make that decision? 

[00:37:10] JN: I think I would go for a little bit of both. I think there is never any downside to learning more in general. So obviously you have a limited amount of time, but it can really broaden your horizon to maybe pick a few different languages and to look at each one and to also evaluate for yourself "what do I like about it? What do I not like about it?" It gives you a sort of broader view. I actually kind of wish that I'd done more of that when I was a beginner programmer. 

[00:37:44] SY: Yeah. If you had, what would you have looked at? 

[00:37:47] JN: Ruby is a very dynamic language, and I think it would have been beneficial to look at, "ok, what's the opposite of that?" And to look at something which gives you more constraints. So Ruby is very dynamic, very open. It lets you do whatever you want to and write software however you want to. There's value in that, but there is also—there are other languages which are much more, much more static and much more constrained which give you less rope to hang yourself with. I think that maybe understanding the, the upsides and downsides of both of these things, that would've given me (Music) more perspective. 

[00:38:32] SY: Well, thank you so much, Jonas, for being on the show and teaching us all about testing and, and all that good stuff. It's been an absolute pleasure. You wanna say goodbye? 

[00:38:40] JN: Thank you so much for having me on the podcast. I hope this has given you some, some ideas about testing, and I, I hope that you try it out and that you explore the world of testing 'cause I think it's really, it's really fun and enjoyable. And I think it's, it's a really great tool and great benefit to have as a software developer. 

[00:39:01] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies or send me an email hello@codenewbie.org. Make sure to check out our local CodeNewbie meetup groups. We've got community coding sessions and awesome events each month. So if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast. And join us for our weekly Twitter chats—we've got our Wednesday chats at 9PM EST and our weekly coding check-in every Sunday at 2 PM EST. Thanks for listening. See you next week.