RR 391: Frontend Testing Like a Rubyist with Josh Justice

    1
    556

    Panel:

    • Dave Kimura
    • Charles Max Wood
    • Nate Hopkins

    Special Guest: Josh Justice

    In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out!

    Show Topics:

    0:00 – Advertisement: Sentry.io

    1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too!

    2:11 – Josh: Thanks! I am happy to be here!

    2:18 – Chuck: Introduce yourself, please!

    2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development.

    2:46 – Chuck: You work for Big Nerd Ranch in Atlanta?

    2:56 – Josh: Yep for the last 3-4 years!

    3:15 – Chuck: Can you introduce the topic?

    3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here!

    5:06 – Panel: How much bouncing do you do between React and Vue?

    5:11 – Guest.

    5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain!

    6:16 – Guest: I’ve had a good experience with Cypress, actually!

    7:47 – Guest: Panelist, can you share your experiences?

    7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript.

    8:30 – Guest: I think there is a big push towards considering more server site rendering.

    9:35 – Panel: What’s your recommendation to setup Cypress?

    9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up!

    10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018).

    10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed?

    11:00 – Guest: Can you clarify what you mean by a “running environment”?

    11:04 – Panelist clarifies.

    11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago!

    12:01 – Guest mentions Vue CLI 3.

    14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test?

    15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend?

    15:24 – Panelist answers the guest’s question.

    16:06 – The guest mentions Vue CLI 2 & 3.

    18:31 – Chuck: Are you using the tool Istanbul?

    18:36 – Guest: Yep Istanbul is the one!

    18:54 – Chuck: I’ve heard some similar rumors, but can’t say.

    19:02 – Panelist talks.

    20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out.

    20:40 – Guest: Talking about test-driven development…

    Guest: Have you read the original book?

    21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out!

    The guest mentions his live stream on Friday’s. Check out the links found below!

    23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that?

    24:22 – Guest: I think we are spoiled in the Rails world b/c of those…

    24:53 – The guest answers the panelist’s question!

    26:59 – Fresh Books!

    28:07 – Guest: Does that help?

    28:10 – Panel.

    28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app.

    30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity.

    31:17 – Guest mentions a talk at a conference. See here for that information!

    31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?!

    Guest: The freedom to create something that stands alone.

    Guest: Tom Dale is mentioned by the Guest.

    33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer.

    35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault.

    35:57 – Panel.

    36:04 – Panel: The counter-argument could say that’s where server-less come in.

    36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else.

    36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and…it’s not easy. There is not a good flow or good work flow in a server-less environment.

    38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features.

    38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier!

    39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing.

    40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future.

    41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not?

    42:02 – Panelist mentions Cypress, Jest, Mocha, and others!

    43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed?

    43:29 – Panel: There is an article written that talks about this topic.

    43:59 – Guest mentions the video “Is TDD Dead?” (See links below.)

    44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 

    46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy).

    Guest: I think the thing that draws me to unit testing is that…

    47:37 – Guest: I am obsessed with testing.

    The guest gives a summary here!

    48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon!

    49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance.

    50:00 – Guest: I would encourage folks who were new to coding to do the following…

    51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why.

    52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there.

    52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API.

    54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier.

    55:58 – Chuck: I have had talks with Corey Haines about topics like this!

    56:47 – Guest: Yes it can be helpful in consultancy now.

    59:23 – Guest: Think about this: choosing what level to test at.

    1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do.

    1:00:41 – Chuck: You are the consultant it depends doesn’t it?

    1:00:51 – Picks!

    1:00:55 – Advertisement: Get A Coder Job!

    End – Cache Fly!

    Links:

    Sponsors:

    Picks:

    Nate

    Dave

    Charles

    Josh