242: Front-end Architecture Making a Way For Testing with Fabio Nolasco

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe. And welcome to another episode of Test Talks. Today we're going to be talking with Fabio Nolasco all about his book Professional Front End Architecture and helping front end developers reach its full potential. In this episode, Fabio explains how front end architects have an opportunity to act as catalysts so that good front end code and testing can actually happen as it should in your organization. Talking about how good testing can occur in your organizations if you're doing any sort of front end testing, one of the concerns is probably performance testing. And that's why I'm so excited to announce that I'll be hosting the second annual online conference dedicated to performance testing called perf Guild happening April 8th to the 9th, where you learn from some of the biggest names in performance testing on best practices to help your teams not only deliver high quality applications, but also deliver high performant applications. Make sure to check it out. Head on over to perfguild.com and register today.

Test Talks is sponsored by the fantastic folks at Summer Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own Selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Fabio, welcome to Test Talks.

Hey, thank you for having me here today.

I'd like to talk to you all about front end architecture and how to make it more testable and and also about your book, Professional Front End Architecture, helping front end developers reach its full potential. But before we get into it, could you just tell us a little bit more about yourself?

Sure, yeah. So I'm originally from Brazil. I moved to the US about seven years ago and I have a very unusual background. I actually started.

My career as a forest engineer which is pretty unusual. But since young age I used to work with computers. So when I entered college I actually.

Work with forest engineering from the computer perspective as a programmer with that computer mindset. So when I moved to the US and I was trying to get into that interface between forestry and computers and I couldn't find.

Position in that interface so I went with what I found. I had the, let's say the best preparation which was computers and I started with a company that is like a Home Depot for factories as a front end developer and walk my way all the way to front end architect And I'm now had experience with some big organizations and now with aig.

Very cool. So forestry to computer science, how did you make that leap? How did you even get into forestry? What is that degree about?

Yeah, that's a great question. Well, I always liked computers since young age. My whole family was confused about my decision. But my goal was that I wanted to apply computers or computational solutions to real life problems. I had a small company at that time. Even in the young age.

I saw the people that were studying computer science, they didn't really understand that the subject matters of the programs that they would create. And there was always a conflict between the person idealizing the system and those creating the system. So I said, well.

Let me work with, if I go to forest engineering I probably can work with programming. And for my surprise there's a lot of programming and computational solutions investigations research.

In those more like rural and biological areas. You know, it was a great surprise to see that there's so much computer science involved in engineering, you know.

Very cool. So it seems pretty niche forest engineering but also front end architecture to me sounds kind of niche. So I believe that's what your book is about at a high level. What is front end architecture and how did you get into that particular subset of computer programming?

Yeah, so just making a bridge between the both of them. So programming inside engineering can actually be way more complex than the challenges I faced when I joined as a computer programmer for the market here in the United States. The challenges I saw as an engineer was actually way more complicated than the the challenges I faced as a web developer, a full stack web developer when I started my career here in the us but then with time I started noticing that a lot of people would treat front end development with a lot of almost would say disrespect. You know, people would laugh at you if you say oh yeah, I work with HTML CSS in JavaScript because there are so many other languages that was way more complex. Right. But I love the idea of working with those three technologies, having a result and immediately seeing like being able to code and have immediate results and show people get feedback. That cycle between feedback.

Cross team collaboration and improvement of a product visually, that was extremely exciting for me. So that's how I started to focus on front end. And then with time I started seeing that front end was suffering from some sort of disease where people just wanted to, including myself, we just wanted to restart every product from scratch. Every time a new manager will come or every time there's a new release for the project. Myself and many other programmers in other companies that I knew of, we just had this feeling, this desire of just restarting from the scratch.

And as you know, that's very unlikely for any manager or company to approve. So I started investigating what was going on, why we didn't have maturity in front end development. We were considered second class programmers right at that time. And that's where the book came, the ideas for the book came from.

Great. So I like to define things just for folks that may not be familiar with it. Most of my people that listen are more tester based backgrounds at a high level. How would you even explain what is front end architecture? How would you would be the definition you would give that?

Yeah. So I don't think there's a industry standard definition, but I'm trying to push or to promote a new perspective. Right. Common perspective I see around in the front end community is that front end architecture is the work of selecting a tech stack. Right. Which CSS or JavaScript framework you're going to use and how you're going to organize your files, how you're going to configure your development environment and maybe even like a little bit of your data flow. Right. That's the most common approach I see. But I think that's pretty limited perspective. And the reason is this. When I started listing all the problems that I saw with front end projects in many, many countries, many companies, I was able to identify some commonalities with something that in computer science people call the software crisis. Something that emerged more, let's say strongly in the 80s, still a little bit within the 90s where maintaining a project was more costly.

Per line of code changed, it was sometimes double or triple the price than it was when creating the application. I don't know if you remember, but Adobe Photoshop and many other applications in the 90s would take several months or years until they would have a release, even though they have very qualified engineers that was following the best practices. So what was going on? What was hindering? And then soft architecture came to as a higher level of abstraction from software engineering trying to solve that problem. And they did achieve great results in the software development, making software release come way faster, way more frequently. And what I did was see what I could leverage from that experience that solved the software crisis and now like how we could get those lesson learned from the software crisis and bring it to our front end crisis, so to speak and see what could I absorb from software engineering for software design, from software design and from software architecture and maybe propose a new Approach from seeing software architecture from a higher level of abstraction to coordinate the efforts, orchestrate the, the initiatives.

You know, you mentioned lessons learned. Can you give an example of like a lesson you learned and how you applied it to front end architecture?

Yes, for sure. So the first lesson I learned, which sounds pretty simple, is that there's no silver bullet in terms of engineering perspective. And that sounds simple enough. But it took people 10 years in the 80s to figure that out until like 1993 more or less, where everybody, like there was a boom of books, everybody wanted to come with this new soft engineer methodology or this new framework that would finally solve everything and make software development streamline. And people really thought that a better technology would fix it, right? So there are so many frameworks coming, so many books and people saying that my way of coding, my way of organizing file, my naming conventions, all of those coding standards and maybe a different algorithm, you know, like something like that would fix everything. And they noticed that that was not the case because they kept embracing all of those good practices over and over, over and over. And things were not getting easier in terms of development and the costs, et cetera. So in front end I see the same thing, right? People kept, kept like from basically from 2009, 2010 all the way to nowadays discussing arguing online, like which framework is the best and maybe the next version of this framework will fix everything and maybe if I just switch to this other library or framework, everything will be fixed and the problems just continue, just get a different phase, but the problems continue, right? And I saw that there was a need to have an orchestrator, someone that was bringing more concerns to the table than just which technology. Because we are well served of technologies nowadays, right? We have so many good technology. We have Cypress, we have Angular, React, elm. There's so many good technologies right there.

And we still have a lot of problems in the front end community. Like developing is not. We didn't reach the level of maturity that we can say, yeah, I create a software, my company is going to hire this guy and he's going to conduct everything and it's going to be scalable and maintainable. All of those ilities, right? The system quality ilities, we're just not reaching it by replacing technologies. That was a lesson learned that I brought it very quick and say, hey, stop, let's stop talking about just technology at this point. Let's see what we can improve in terms of process and methodology, right?

Absolutely. So as part of that process and methodology, back in the day, when I started most of the Logic was on the back end and the front end was just like you said, an HTML page. But nowadays with the front end technology like Angular and React, you could do a lot more on the client side. So things that used to concern me with performance just be on the back end, but now I need to worry about the front end. So as a developer or for a front end architecture, how much does a developer need to be aware of these type of issues that may bubble up in testing like security testing or performance testing? Is that something that is part of your framework when you're thinking about the actual architecture of the front end?

Yes, it is. And that's partially the reason why I wrote the book. Because I could have just say, well, we already have software architecture, why we create a front end architecture, why not let software architects take care of this and organize everything? It's because the front end world is too broad and it changes every week. As I told you, I have a force engineering background. If I decide to go back to that in 50 years, trees are going to still be trees, right? But if I just sleep, if I get in a coma for 10 months and come back, the front end world is completely different. If it's difficult for developers to keep up with those things, how they can watch out for architecture and also their work and also keep up with all of the discussions on W3C, ECMA community and all of those browsers and see what's coming, what is being deprecated, it's just too much for them. So this idea that a developer would be capable of monitoring the whole company in all the front end initiatives in all departments and everything that is happening inside the company, outside and at the same time watch for all those things. It's just almost overwhelming. It's overwhelming actually for most people that I know of, including managers. So the way that I think this methodology helps is to bring this concern to them by kind of doing part of their job. Instead of them spending hours and hours online researching seeing who is right, who is wrong and.

Which answer better applied to my company. Architects would have that work capacity to end, the knowledge to be researching and have more visibility within the company to see what is the best. And sometimes, you know, have you ever participated of those Friday meetups in the company where someone shares what they learned and that's very valuable, right? Like instead of you spending three hours online researching seeing what is what, then you just have the quick meeting on a Friday or Thursday, I don't know when you used to meet up, but then a co worker, a friend would come and just share the conclusions and the highlights. Just save so much time. And that's basically what the architect would do and already say, okay, so there are those coming changes in the browsers and those changes on JavaScript. So maybe we can just hold off on these and just this feature and maybe prioritize this other one, you know, and that saves everybody time, save the company millions of dollars. Because if all of the developers are not coding and not producing and they're actually trying to figure out what, what is the best practice or the recommended practice from other teams to keep in line to increase reusability, then the company is losing time and people are losing time as well.

Absolutely. So I'm just curious, since you are a front end developer architect, at what point, if any, does testing ever come to mind? And the I bring it up is a lot of times testing seems to be an activity that's done after the fact. And I have to tell people, look, you can't test something that's not built to be testable. So do you have testing and at what level do you incorporate testing within your architecture design as you're developing these applications?

Well, that's actually a complicated question just because the real answer is not the right answer. So.

The right answer is yeah, we test everything and everything's done perfectly. Right. We do TDD and everybody is making sure that the tests are well written and well maintained. That's the perfect answer. But the reality, my reality as well as of every other front end developer that I know, they are not working for a tech company like Google. Right. The reality is that they're so buried with work, they're so concerned with their deadlines. Right. They're so behind that they tend to lower the priority of, let's say, testing and documentation things that they don't see as crucial as delivering the actual features of the project. Right. And I think they kind of get away with those things because manager, in the end of the day, even though managers might feel a little disappointed that the code was not as tested and as documented as it could be, but just the fact that the guy is actually delivering something, results and the project is moving forward, I think most managers that I know of, they just kind of let it, let it slide, you know, so testing most companies that I have knowledge, the companies I know the most are non tech companies like let's say big, big E commerce websites and some companies on the financial industry. And so those companies most of the time they handle testing unfortunately only after the code is passed down on the DevOps pipeline and.

A Q and A sort of department will take over and kind of create some H tests and, and monitor it. But very little testing during development and almost no update of those tests after release. Because I can even give another reason for that. If you were to get a job at Google or Apple or I don't know, Netflix. Most developers tend to stay a longer period of time because it's a great opportunity, it's great for your resume, it's a very exciting work environment. But when you go to a financial industry, e commerce, everything is done very slowly. Why? Because they're subject to audited from the government and every technology that they need to approve go through a scrutiny process. Legal departments, it's very lengthy process. So the developers that work there tend to not stay very long. They have a lot of contractors from other countries, from Eastern Europe, from India. So that rotativity of employees make them more concerned on delivering the results and less with documentation and testing.

You just described the environment that I'm in. It's a healthcare company and exactly how you explain it. But there has to be some. How do you make it so you explain to people the value of testing and how can you actually do testing that in a sustainable way adds value, I guess is the question.

Yeah, I like to believe that most developers are very smart people. Like at least the ones I have contact with, they are incredibly smart. So when they study testing, I think they can understand the value of it. The question is how can they do it? I think they would do it if it was doable, if it was easy or if it was pleasant. And if you wouldn't sacrifice something in the end of the day they are trying to survive. Someone cut something off. I never met a developer said I'm not going to do testing because I hate my company and my boss, right. They usually say I need to deliver this. And they're afraid for. They're trying to save their own skin, right? Like they're worried about their payment at the end of the month. So I see the position of a front end architect. Crucial to find ways to make that happen. Because I like to give this analogy when I explain this. So think of, let's say a H Vac company. Okay. Suppose that you create a H Vac company and you were hired as a manager there. Okay. And you, you notice that people were next, were not really looking to the, the motherboard of your units. You decided to put some metrics on your, I don't know, you make a smart drill. You know, they will See how many times they're actually using it to unscrew things and etc. And then you see that the people are actually not opening the boxes and they're not looking to the motherboard, even though sometimes they check that they did. And then you say, okay, let me get a better screwdriver that's faster or let's say easier to you don't need to put it like exactly on the hinges of the screw. And you spend millions of dollars and you get the best drill and still people don't change anything. And you move to training and try to make people understand the importance of checking the motorbo. Still people don't do it. So sometimes the solution is not actually giving a better tool or trying to find the better technologies. Sometimes what we need to do is to analyze from a more subjective, more holistic perspective, why are developers not doing it, what is hindering them from doing quality testing suites. Maybe you're going to see that maybe all you needed to do is to put a magnetic tip on your drill. It would cost the whole company maybe $500 to fix everything. Because since it's a darker place and it's not well finished, sometimes the screw will fall down, the guys will need to spend five minutes looking for the screw, something like that. Or maybe all they needed was a headlamp to make it easier for them to find the screws or something that will also cost a fraction of the investment done. So not everything is about getting better technology.

And that's what the front end architect comes in place sometimes about. Aligning technologies, make sure that all the technologies across different teams, the ERP system of the company will accept it. It's not always the best technology, sometimes it is the better fit. And when you make that happen, when you make testing doable, not threatening for the productivity, not complicated, I think people gladly do. I don't know you, but when I first wrote my first test and I got it wrong and then wrote it again, it passed and I got the green, I felt a whole lot of satisfaction.

Absolutely. And you actually proposed some ways that you found testing that makes it easier for a developer and their workflow. And one of them was visual validation testing. Is that in your experience, something that a developer could get behind pretty easily without interrupting their flow or having to dive into like selenium code that they may not be familiar with?

That's the best, let's say, practical thing I can do because everything else we discussed so far are principles. Right. And it's something that I had a hard Time getting my wrapping my mind around because as a programmer I wanted like something practical, a tool, something to do immediately. But when you start moving towards architecture perspective, things becomes a little more principles. In principles, you need to contrast with your situation in order to find a solution every time, right? There's no step by step. But fortunately, to answer your question, fortunately I did find something that was incredibly practical and actually as a even helped me shape the name of the chapter of my book, the chapter about testing. I called it the Testing Revolution because I did find one thing that was actually hands on that we can do to make everything better. And it is applitools. And I know that it's one product, but the reason I mention it by name is because they currently don't have anybody that even get close to them. There are no other tools that matches their product, their power. And so so far, if I need to fix testings in any company I go to, I present and they immediately get it because they're unmatched. And what applitools does is they do visual regression, they take those screenshots, but. But they have a lot of artificial intelligence. I don't know if I can call processes at the end that make it way smarter than just comparing images. What I learned through my experience is that it made unnecessary to write as many unit tests and not as many integration and end to end testing. So now instead of having a developer write hundreds or maybe thousands of unit tests for a big application and a lot, a lot of integration testing into a test, they would write only some essential ones. And because it's a smaller quantity of tests, it becomes more manageable and becomes more pleasant for the developers to write. Not that applitools came to replace those kind of tests. Applitools actually work in partnership. They didn't mean to replace, but they did make it less necessary for companies to write that amount of unit tests. So if in the past I was writing about 300 unit tests per project, like very forcefully, almost like in a threat level, like hey guys, you need to do it, otherwise we're not going to get approved by our DevOps or something. Now that became less necessary because one screenshot can cover more things than I could possibly more tests than I can possibly write on my own.

So I definitely agree. I love applitools. Another tool though you mentioned, which may seem like a no brainer, but maybe a tester may benefit from it is Chrome Dev Tools. Why are you so. It seems like you have really high on Chrome DevTools can you explain that a little bit.

Yeah. So Chrome DevTools until very recently was unmatched. I think Firefox are doing a great job making their devtools also very nice. But I would say that Chrome is still on the top as well. They're still the best resource for front end developers to examine their codes, run, put test points and break it down. And it's funny because a lot of people think that it's just a little tool to learn, but every time I create a little workshop about it, Even like with 8 hours of workshop, we cannot cover everything. It is really big, it has tons of features and I signed some kind of podcasts and things from. I think it's Omar Hansa and other guys. Oh my God, those guys work hard and they have a lot of new things coming every week. There's also a YouTube channel for Chrome dev tools or what is new in Chrome. And they have always launching new tools within Chrome development tools. They're just incredible. It's an essential part of front end development. And as an architect, one thing that I can do for my team is to keep bringing those things instead of them studying and keeping up with this every single day. I can just make a little compilation and just come in once a month and say, hey guys, you guys can certainly benefit from this new feature.

Cool. So DevTools, is that something a tester could use as well if they're doing maybe exploratory testing to check performance or how things are loading or anything like that?

Oh yeah, for sure. There's so many tools. There's one for example, that I like a lot, which is a high resolution timing API. I love creating those points, making sure that I use the binary search approach. I divided my application in blogs and I start making the binary search so I can find which part of which function is causing the biggest, let's say performance penalty as I interact with it. But as they are changing all the time now, even when you examine your code, you can see how many seconds each function took. There's a code coverage also panel on the Chrome development tools that you can see. You just keep using your website and you see which part of your code is actually being used and what is the percentage. You can come with crazy numbers. You can say like, hey, 60% of your CSS is never used and actually open every single screen of the website. So maybe we can trim this down. There's a lot of things we can do to help performance.

So Fabio, I guess I hinted around to this. I didn't officially talk about it. But a lot of the questions I got were based on your book, Professional Front end Architecture helping front end developers reach its full potential. I guess the first question is why did you write the book? And two, probably how could people get their hands on this resource?

Yeah, so the book is on Amazon and it's actually for free through Amazon Unlimited. So I want to make it accessible through that means. But the reason I wrote this book is because throughout history, since 2002, 2005, with Ajax coming.

Google Maps, popularizing engine, mail, right. I noticed that front end development was not taking as serious as it should be because companies was just treating front end as one like a little detail on their pipeline and they didn't see that actually a lot of the backend code was moving to the front end and we had huge challenges. Right. If we need a good engineer and architect to make a building skyscraper, we certainly need an even more active and experienced architect to do the same, but with more rudimentary technologies.

And I noticed that also that millions and millions of dollars were being invested in front end and not a lot of technical concern was put into it. It was more like, okay, we worked a lot, now the front end guys just go and make it happen. And those millions of dollars were being lost. And there's a lot of space for improvement of efficiency. And I believe that any company that improved their methodology, how they manage their front end, shop every single feature that they can save from previous version, every application they can avoid, rewriting would cause them to have this extra time, this opportunity to actually add more business value and get ahead of their competition. So instead of spending three months rewriting an old application and with proper architecture, the same code can be maintainable and it can be updated in a fraction of the time. And releasing developers to add business value, create a new feature, something that from the user, the final user perspective is more valuable than changing which framework I'm using.

Right.

I don't think a lot of people care which framework is used as long as the website is fast and operational. So that's why I wrote the book. I think there's a lot of space for us to improve front end development, including testing.

Right.

There's so much opportunity, we need to find ways to improve testing in front end shops. And I don't think by just keep changing technology over and over, over and over will fix everything. So I didn't mean to make my book a final word, but since it's the first book of its kind, I really want to get the front end community started in those discussions and getting robust methodologies to govern their projects and their development.

Awesome. So a lot of times a tester creates frameworks, automation frameworks to test their code and a lot of these principles, especially front end architecture design, would apply to that as well. So if someone's listening and they don't think this applies to them, that you could pull a lot of these principles and best practices out of front end architecture design and actually apply it to creating a test automation framework as well. And you get a lot of the benefits that you mention in this book. So thank you for that. Okay Fabio, before we go, is there one piece of actionable advice you can give someone to improve their front end architecture efforts or testing efforts and let us know the best way to find or contact you.

Sure, yeah. The best advice I can have for people to improve the quality of testing their company would be for them to get their bosses to buy into the idea of having an architect. An architect will pave the way, will make a way for the cars to run smoothly, and you're going to have way more work capacity to focus on testing and doing better quality testing suites. And the best way to contact me is FabianoLasco.com you can reach me through several means there. I have a Twitter, Facebook.

I'll do my best to answer every question.

Thank you Fabio for your front end testing awesomeness. For links to everything of value we covered in this episode, head on over to testtalks.com 242 and while you're there, make sure to click on that Sign up for our free Trial link link under the exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. So that's it for this episode of Test Talks. I'm Joe and my mission is to help you succeed with creating automation. Awesomess. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over over to www.testtalks.com for full show notes, amazing blog articles and other automation awesomeness.