Check out a free preview of the full Enterprise UI Development: Testing & Code Quality course

The "Enforcing Standards Q&A" Lesson is part of the full, Enterprise UI Development: Testing & Code Quality course featured in this preview video. Here's what you'd learn in this lesson:

Steve answers questions about getting team buy-in for more comprehensive testing, component testing, building API transition layers.


Transcript from the "Enforcing Standards Q&A" Lesson

>> Now, how do I convince my team to do all this stuff?
>> That's-
>> It's a question I always have.
>> Yeah, I mean, let's talk about that a little bit. That's a tricky question cuz every team is different, right? I have had the secret advantage of, I've been able to pull rank for a really long time now.

Do you know what I mean? So I am not the best person to answer that question unfortunately because I've either been the most senior engineer or everyone's boss, right? That's a new, previously, I was just, whatever, at least had no actual authority, but at least a title that made people think that I had some power.

I had no power as the frontend architect at Twilio. It was mostly me kinda trying to salesmanship and charisma my way to getting stuff done, but there was probably an illusion, right, that I was fancier than I really was. So it not always depends on the team. But I think part of it is, to be honest, cuz I was anticipating a question like this, so I thought about it on the plane.

I think part of it is, I have worked on teams where the person who wants to have the most, Ambitious lint rules, how about that? And there the person wants to have a 90% code coverage enforced thing. Not always the exemplars on the team, right? And so it's hard to make that.

And so I think part of it is leading by example is my way of saying that, which is like, hey, I'm willing to hold myself to this standard and look at the positive change. And understanding change management is a whole thing in and of itself, right? You don't want a New Year's resolution, this stuff, which is, you know what, new rule, we're gonna have all of these lint rules.

You add one, one after an incident. You know what I mean? One after we caught something, and then you add a second one a little bit later, right? And you slowly, people don't want the world changed out from beneath them, they have jobs to do. Yes, everyone wants to work in a healthy code base and everyone wants to be fit and all of these things, right?

And the answer is not necessarily like you're gonna immediately change everything all of a sudden, it's like maybe you just put on your running shoes in the morning, you don't even have to go over a run. All right, and all that stuff that you read in books from the airport applies to your code base too, right?

And I think that kind of small change management getting people on board because there is a value. These patterns and practices don't exist for the fun of it, right? They exist because they work, but sometimes you people need to, you start with something small, people see the value in that.

You kind of move the Overton window a little bit, and then you do the next thing, right? And then slowly, everyone's like, remember when we had to manually test every PR for two hours every Friday so we could release on a Monday? Yeah, that was bad, good thing we don't have to do that anymore.

And you're like, let me tell you about enforcing rules on commit messages to automate the release notes so that I don't have to write them by hand. That one's gonna be a harder sell. They all said yes, but I haven't done it yet. Do you know what I mean?

I think that when like, because I do it all the commits against whatever. You start with like let's have a more maintainable, you start with those playwright tests. Boom, right? Yeah, they're slow cuz they clicked everything on the app and they're like two of them, but then they caught a thing that we didn't ship to production.

[LAUGH] Dope, right? Let's do the accessibility checks on just the design system components, right? Unless maybe just as warnings to the beginning, now we have fully accessible and compliant things. And then you hope that the reason I found the lint issues is I had a bike, two people from sales and two people from solution architecture going like, just a question, what is it?

What is it, w?
>> CIG, okay?
>> Yeah, are we that compliant? And I'm like, let me check, and that's when I found out the issue. I was like, no, but we could be like, no, it's not a big deal, I was just asking cuz someone asked. And I was like the third time someone in a week asked me that, I'm like I understand how this plays out.

Three months now, they wanna sign a contract, and they have our stipulation and now we're pulling all hands on deck move. So we just slowly dealt with them, and that hasn't happened yet. But my suspicion is that in a month when it does happen and we're like, yeah, we're ready, that value add for the team is there that we didn't have to go through that death march.

In order to do it, I think that stuff starts to accumulate over time, and that's how you make the change. You don't come in like, yo, I went to this workshop for two days and I think we should lint all the things and break everything. Code coverage, it's gonna be 1,000, you are not gonna be everyone's favorite person, [LAUGH] right?

And it's about figuring out the long term, the quote that I think a lot about just as a gen. If you wanna end this on life philosophy, here's the quote I think a lot about, it's pretty true to six different people. Let's take your favorite pick, which is people overestimate what they can do in a year and drastically underestimate what they can do in ten years, right?

And those small changes add up.
>> How do you manage testing components where you have to navigate to a particular route in order to render that component?
>> You have two choices, right? One is you can take the browser and go for it, right? But that's probably not the answer that you wanted.

The other piece then is it comes down to the doing the work to break out the components so you can lift it out of the codebase. And that's where a component has, yeah, there's so much stuff happening, marking out the entire world is gonna be hard. At that point, with a certain amount of passing the dependencies, can you get to the point where everything that it needed for where it was lodged into that code base?

Can you pass those things in and then pass them in there and then lift it out and then pass in a similar? And TypeScript here makes it a little bit easier to because you will get yelled at if it is not a compliant function lifted out. And then that's where I might choose to use a component test, right, so that I don't have to navigate all the way there, right?

But it's tricky cuz it's very easy to talk about in the abstract, it's very easy. You just left out your component testing. Yeah, I tried to do that for two or three of the examples here, and I found out that even in my code base, a little bit easier said than done.

In all fairness, I had to weigh, I'm not lifting this out for anything other than an example. And I had to weigh it against what's faster writing a fictitious example or lifting this out for no actual value other than that. And so yeah, there was that, but even in my own code base, it's like I understand that a lot of the stuff is easier said than done.

To my point earlier is you wanna do all these things tomorrow, right? With the entire tool set that we talked about, there's probably something that seems the easiest, right? Start with that, slowly improve the code base over the next year, don't try to fix it next week.
>> What does the translation layer look like in code?

>> So the concept I stole from Ember, it is whatever garbage deeply nested object that some backend engineer thought was a good idea cuz they just stitched it together from a bunch of other objects. Cuz they're used to, yeah, I need a flat thing to have some props that I wanna dig down, whatever, like gnarly.

Objects were, the thing that I need for the H1 or the H2 is seven layers deep. And in every component where I need it, I'm going down there. It is literally not different from that ESLint rule that we saw. But it is literally a thing that takes these gross objects that I'm used to dealing with all the time and makes it into a nice, flat, easy object where everything's formatted correctly.

That is almost the perfect example of what you could unit test. You grab the JSON, you go into Chrome, you go to your network tab, you hit copy response, you paste it into unit test, right? Then you expect it to be what you wish that your API was.

And then you start doing things until it is. And now, instead of calling fetch, you call that request from API, you call get whatever is in your app. Everything passes through there, right, and gets formatted the way you want, and you never think about your gross API again.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now