Hey, Welcome to Adventures in Angler, the podcast where we keep you updated
on all things Angular related. This show is produced by two companies, Top
and Doves and Onvoid. Top and Doves is where we create top and devs.
We get top and pay in recognition but working on interesting problems and making
meaningful community contributions. And Void provides remote design and software development services on a
task basis, so clients only pay after the tasks are delivered and approved.
In today's episode, we will talk about ng demo and just overall testing practices
on Angular applications. My name is Lucas Paganini. I'm your host and a
podcast and joining me in today's episode is a very special guest, Matt.
Matt, let me know if I butcher your surname, but I believe it
would be pronounced rabel. Is that that's correct? Awesome? Awesome, got
it right? Nice? So. Matt is a web developer and author of
the Angular Minibook, a practical guide to developing apps with Angular and springbook,
and as part of the of this book and the content that he produces,
he created well. He has a repository which is called Angie Demo and it's
a demo application using some of the latest versions of Angular, and he also
set up testing automated testing in this repository. So what we're going to try
to talk about more in here is how did he set up automated testing in
this repository and some of the different ways in which Angular developers are doing testing
nowadays, because we have the native Angular modules for doing testing, but we
also have Cyprus, we have Playwright, we even have Storybooks still that allows
us to test individual components, and there are some other companies and tools such
as apply Tools. So this is kind of the overall introu for those of
you that might be interested, stick to it, and we're going to start
going deeper into that topic now. So Matt, just so that we can
start out, first off, thank you for taking the time to be here
in the show. I really appreciate you you being here. And let's just
give people an introduction on how things are structured on Engie Demo in terms of
automated testing. So in NGI demo, it basically just has unit tests for
components and they're they're very simple, right They They basically don't really do much
accept verify that the component's been instantiated, right, but that's very helpful to
know if any errors in your component. And then there is a service test
as well, because there's basically a service that calls out to get like a
list of people that are rendered in the UI, and so in that test
there's more like mocking that happens, right of like the HTTP request and verifying
you know that certain data comes back. And then there's also end to end
tests which are driven with Cyprus and for the most part, you know,
the the ng demo app is very boring or simple, right because I call
it like the bare bones basically Angular app, regular tutorial and Cypress is just
verifying that the functionality works. Right. It has a list screen of happens
to be Denver Nuggets players you know in the NBA, and you can you
know, click on them and edit them or you can add a new one
and that's it. And it's just talking to a Jason file. It uses
like in memory storage, so it's not talking to an actual database versus like
the Angular minibook shows you how to talk to an Angular data or a database
in the back end with spring boob and so that Cyprus test is very simple,
but there's also GitHub actions that show how you can automate it with CI.
And then there's there's different branches for Angular material. There's one for Bootstrap,
there's one for US zero, and there's one for electron. So it
kind of you know, verifies like with a zero that you can actually log
in right to an application. And so you know, a lot of that's
just to show you the bare bones that you need for testing infrastructure. Awesome,
awesome, Okay, Well, one thing that I think we can get,
we can create a distinction for people just to get started on this discussion
is the different types of things that we're going to be testing right, Because
if you're just testing logic, like for example, pure functions, then my
approach is always going to be just right in regular unit tests, and that
can be with Jasmine, that can be with Jest. I don't care like
whatever comes with the framework that I'm using. So I know that nowadays it's
much easier to use Jest with Angular and Acts for example, allows you to
very easily run Angular tests using Jests instead of Jasmine, which used to be
the default test runner for Angler. So nowadays we have this this option.
But if you're using Jasmine or JEST, I really wouldn't mind because their syntax
is pretty much the same and they do the same thing. So if you're
just going to test pieces of your logic, so for example, function acts
should receive those arguments and return that value, then just write regular unit tests,
don't even bother with the framework. So try, at least myself,
I try to isolate the parts of my application that are not framework specific and
really make them not framework specific, you know, like everything that is just
a business logic. I try to not make it too coupled with Angular and
just have regular pure functions that declare this business logic and just test those individual
units. But then for anything that requires me to interact with the front end,
then I'm not going to shy away from using Angular. And in those
scenarios that would become a service. Right, So that's either going to be
a service or an injectable function, right, So a function that runs within
an injection context in Angular and in such scenarios, then I would still write
a regular JEST or adjustment test, but then of course I would have to
use the test bad from Angular so that I can declare the service as a
provider in there, and then I can get an instance of the service to
run tests against it, so that would be the only difference. But when
it comes to visual testing, so when it comes to actually testing a component,
for example, an accordion, So let's say that when you click on
the tuggle, it should expand and show the main content of the accordion,
and when you click on the head again it should collapse. For those things,
my current approach is to not write angular tests for that, and what
I would rather do is just write an end to end test for the main
crucial clows of the application, and I would do that using either Cyprus or
Playwright. So I would not be testing the accordion itself. I would not
be testing that the accordion expands and collapses. I would just be testing a
flow that perhaps uses the accordium, so it would be tested as a byproduct,
but the test wouldn't be about the accordium. It would be about a
user flow that just happens to use the accordium. Right. So the downside
of that is that I have less coverage of my components because I'm not really
testing all the different things that the accordium component could do. But the good
thing about this is that I'm testing what actually matters to the users, right,
which is that they are able to complete their actions. So there's a
downside there, but to me it just feels faster. It felt that all
the times in the past that I try to write component tests in Angular,
like using the test bad, instantiating the component, simulating interacts, you know,
like colicking on the head and seeing if the content appears, I think
that it didn't felt natural. I wasn't really testing it how the users would
test it. So these are the ways in which I'm approaching testing currently.
I would be very curious to know how you're approaching it conceptually. So just
to summarize, I separate the things that I test between functionality and presentation.
For functionality, if I can make it as simple as a pure function,
then that's what's going to be, and then I just use jest or Jallesman
to test it. If I really need the Angular framework, then I turn
it into a service or an injectable function, and then I use the Angular
test bad to provide and instantiate that in order for me to test. And
that's the logic side of things. Whenever I create something for presentation, so
an actual component, then I'm not currently writing unit tests for those components.
What I do is I just write end to end tests with either Cybers or
Playwright that test flows in which that component might or might not be used.
But yeah, how do you approach this? Match? But I think your
approach is correct because a lot of times unit tests should be testing logic,
right, and if you have components that just don't have a lot of logic
in it, then you're probably writing unit tests to test the framework. And
if you're using a framework, you should pretty much trust that that framework works,
right, And so I think your approach is good there. I think
the beauty of end to end tests is they can be used for your app,
especially if you're migrating from one thing to another. I know, you
know, thought Works has had a lot of consulting around micro front ends and
migrating from Angular JS to like react, right, so just a portion of
the page has like React on it, or maybe it has you know,
the new version of Angular instead of Angular jass. So by having those end
to end tests, you can help migrate, you know, from one framework
to another or one concept to another. And it's not just you know,
verifying that the UI comes up correctly. And so jay Hipster is a project
that I work on, an open source project that we use just instead of
Jasmine, and Jasmine is used in my ENNG demo because it's just bare bones,
right, I'm not trying to use anything, you know, outside of
Angular, and we have like seventy coverage on all the components, but we're
also generating the code, right, so when you generate code, you want
to make sure that they're tested well, and so that one is a bit
more unit test heavy. But if you look at the components in there,
there's a bit more logic in them than my bare bones example. And then
as far as like end to end tests, I think it's good to have
CI that's verifying everything works. But I've spent a lot of times in my
career like babysitting SEEI I call it because it has false positives. And in
fact, on the jay Hipster project, when we were using Protractor before Cypress
existed, we would have failures all the time that you couldn't reproduce locally,
and so we basically saw a protractor as a burden, right, and migrating
to Cypress really helped us a lot. But I think you know, front
end developers typically don't write as many tests in my experience as back end developers.
But I think what you need to remember is that if you're not writing
tests, you're just not automating things that you're doing already, because as a
front end developer, you'll be testing out the UI all day manually, and
you can really speed up your workflow if you use you know, end to
end tests or something similar to basically automate it. But it's never going to
replace like the visual kind of testing, right because one experience that we had
in Jay Hipster was, you know, we upgrade the the latest version of
Bootstrap and all of a sudden, like the red buttons and the blue buttons
had black text on them, and our CI would have never caught that,
right because we're not getting that to a granular level. And then we found
out we had a stylishoot that was overriding the default of white text on a
you know, blue background. So I still think even though and the N
tests are great, you still kind of want maybe a human involved or some
sort of visual testing frame involved. Gotcha. Yeah, That's that's a very
good point. Is if you're testing components the same way that you're testing logic,
then you're not gonna you're not gonna see right, Like you're literally not
seeing what the component is doing. And thus if a color changes, or
if something is rendered in a different position as where it should be, then
your test is probably not going to get that. You could write a test
using protractor or or something like that to test this, I guess, but
it would be more effort then using tools that have visual regression tests. And
that's where we start leaning on some of the solutions that exist nowadays to facilitate
component testing, which, to be perfectly clear, I have not explored long
enough to tell the audience like, oh, hey, I tried this and
you can go this direction. So I really don't know, but I think
it's interesting for us to at least tell the audience what exists nowadays. Right,
So, I know that Cypress component testing is a very easy option nowadays.
They even have native support for Angular components. So if you go to
the Cypress docs and you go to component testing, there's an overview there with
a very basic example of how you would test an Angular component, and it's
just so easy to follow along with the test implementation, really very easy to
understand how the test is written and what it's doing, what it's testing.
So Cyprus does seems to be getting this right at least when you look at
the docs. Right when you actually start writing the tests, maybe it becomes
more complicated than how it looks in this very simple example in here. But
it's nice that they do have an API dedicated for testing components, and they
already have native support for Angler. But then we also have a very established
alternative already for component testing, and not just component testing but just but also
how can I say the point are previewing components, right, which is Storybook.
So it's been a while since people talk about Storybook. It's not a
hot topic anymore. It was a few years ago. But Storybook already has
a test runner, and with their test runner, you can do interaction tests,
you can do accessibility tests, you can do visibility tests, and that
all comes with a tool which was already designed specifically for dealing with individual components.
Right, So by using Storybook, you also get that nice application that
you can deploy and allow your designers to play around with the components to see
if it's how they envision them. So that's definitely a tool that I would
also consider, because it seems that it was built specifically for this, whereas
Cyprus wasn't really built for components, right, it was built for end end
tests, and now they are also allowing us to use it to test components,
but originally wasn't built for this. I wonder, Matt, have you
ever explored some of those options. Maybe you have others that you you know
that exist that we could at least how at the audience so that can research
more. But I have heard a storybook and I've you know, helped like
edit and published blog posts about it at my previous job. But also it
was also in a React context, so until today I wasn't even aware that
you could use it with other frameworks. But I also think a lot of
times the reason we might not be using something like storybook is a lot of
times I'm developing apps right and testing apps, I'm not developing components in testing
components. Like I think if you're a company that has a component library,
you might be using Storybook more because you have designers that are like interacting with
that library and trying to make it work. But I think what you've seen
in the Angular ecosystem is a lot of libraries are open source as well,
right, and so it's typically a small team of developers trying to make something
happen. It's not more established like a company would be with a design system
and you know docs that document how everything works and use you know, something
like storybook and it's testing feature to verify everything works. I think that's that's
a more formal system, and as developers are more used to just you know,
getting down and dirty with the code and making it work that way,
especially with app development versus component like library development. Yeah, that does make
sense. I also didn't you that Storybook work with other frameworks until a few
months ago when I decided to. Well, actually it was because I saw
that NX had an add on for it, and NX was originally created in
a very Angular centric context, so I just thought it was interesting when I
saw Storybook inside NX, and then I saw that they actually do support other
frameworks. They actually support not just React and Angular, but many others,
like if you just go to their website now I believe that they support View
as well. Yep, so React, View, Angular, Svelt as well.
So that's pretty pretty interesting. Seems that they really expanded their support even
native web components is something that they are also they're also supporting at this point,
which is pretty cool. I was going to ask about Spelt because you
know, I'm primarily a Java developer most of my days, right, and
I also am one of the few Java champions that likes JavaScript and Typescript,
and so it's very interesting for me that in the JavaScript world we have Angular,
React, View, and Spelt, and they've been around for almost a
decade now, right, But in the Java world maybe it's the same.
In the dot net world, there's always joe about a new JavaScript framework,
you know, every week or every day or whatnot, and it really hasn't
happened for a long time. So it's funny that those jokes still exist and
that perception still exists when it's not really true. Yep, yeah, that's
true. I'm really amazed at the amount of tools that a few years ago
only existed for React, and slowly they are expanding to work with other frameworks
as well. It's really nice to see that we from the Angular community are
getting support from more tools. Still, there are lots of things that I
wish existed an Angular that are currently just React specific. So just one quick
example that comes to mind is Radish radix uy. It's a headless components that
you can style and it really saves a bunch of time. So there there
are some things like it for Angular, but there isn't a Radix implementation.
And also I think Framer is a design tool which is similar to Figma,
and as far as as I'm aware, it allows you to drag and drop
React components into it, but it doesn't work with other types of frameworks,
only React components. Well, I wouldn't be surprised if there is more support
from these tools for Angular because there's kind of an Angular renaissance happening now right
where it's adding more features. It's not just upgrading and becoming faster. And
now there's even the talk of combining with wiz right, like that's happening at
Google, which is what I think powers YouTube or something like that. So
it's more performance based, and so I think you will see Angular get faster.
And then React isn't really a framework, it's just a UI kind of
you know framework, right, It's you have to pull in reducts and everything
else to like make it a full on frame. So I wouldn't be surprised
if for the next few years, right, like, Angular starts to be
more popular, and a lot of that's because, you know, we're getting
newcomers into the field and they don't have this legacy of one is better than
the other. They just want to learn something and get a good job,
you know. Yeah, definitely, definitely interesting interesting. Okay, So currently
just recapping if you were nowadays to start an application from scratch, an Angular
application, what would you explore in terms of tools for testing? Would you
so end to end for example, would you go straight to Cyprus or would
you explore lay right. I heard there's another one called Apply Tools. I'm
not sure if it's end to end or component testing, but I believe it's
end to end. So most of my experience with Apple Tools is just because
I had someone to admire work there, which is Angie Jones. Now she's
a TBD or block writer or cash app like that whole company Square and all
that. But I believe it was a visual testing framework. So I tried
to make it work on a blog that we had that basically showed how you
would, you know, use like macros and stuff to spit out a bunch
of instructions on how to like log into octa kind of thing, and so
I wanted to basically verify that, you know, if anyone changed these certain
files, like all the instructions would still render. So I believe app with
tools is good at that. I just never got it working right. But
the whole point is like it will notify you I visual regressions take place,
and so as far as you're asking about the tools, I would choose a
lot of times, if it's a full stack app, I would just use
what jay Hipster has, right because jay Hipster uses like just for unit testing,
uses Cypress for inten tests, and we've had a lot of luck with
that using GitHub actions. And if it's a view or React, we have
support for that as well. So as you know, primarily an Angular person,
I can look if I'm on a React project and see how jay Hipster's
doing it. Like I don't have to use ja Hipster for the the app.
I can just generate apps with it and see like the code it's generating.
So that's that's very helpful. And a lot of times, you know,
people especially enterprises, aren't creating brand new Angular apps right there. They
have an existing app that they want to replace part of right. So a
lot of times you don't get like the green field where you can pick all
the different tools you might use. I mean it might be, you know,
there's a team that runs the back end, and the back end is
PHP or Java dot net, and they choose Playwright because they have experience with
that, and so you might not get a choice to use Cyprus. Right,
the corporate standard is Playwright. So I think you kind of use what's
available depending on the project. Now, if you're developing your own thing,
it's a whole different ballgame. Right, you get to choose, but you
know a lot of times you will end up with a team and then you
might have to choose from that team's expertise. As far as Playwright is concerned,
I haven't actually used it. I believe it's a Microsoft product, But
we did have an issue in the Jay Hipster project where people were like,
let's explore this, let's compare it to Cyprus, and let's implement it.
So give our users a choice whether they want to use Cypress or Playwright,
and it basically never got off the ground. So the main person that was
interested in it never found the time. I don't know if they had small
kids or whatnot, but you know that often takes people's after hours. Gotcha.
Gotcha? Okay, And by the way, you mentioned j Hipster,
but I don't think we gave a description to the audience of what j hipster
is. So jay Hipster started as an Angular JS front end generator and back
end was in and then spring boot came along in twenty fourteen and we kind
of adopted that. So and we've kept up with Angular over the years.
Right, So we started with Angular JS and now it's on Angular seventeen and
so it's it's basically an application generator, full stack APP and with springboot you
can package it in a jar they call it in Java, and so it's
a single artifact that has your whole application that can be running front end and
Angular back end and spring boot. And it can also do micro services and
microfront ends. So if you want to have multiple micro services spread out because
you have different teams working on different components, then you can do that.
And the cool thing with microfront ends is those front ends can be a part
of that micro service and then there's a gateway that has you a shell that
pulls in all those microfront ends using module Federation, and so it's a school
project. It's been around for ten years. I wrote a book on it.
I will as like the lead security engineer for the last six years,
and I recently became like a project lead. But that just means I'm doing
releases now, so hopefully those will happen more. But it's been a fun
like way of showing people with the cutting edges in Java land and you know,
with the JavaScript frameworks. Yeah sure, cool, Okay, Okay,
Matt, I think we can start wrapping up the time went lying, but
we're almost at thirty minutes of content at this point. I'm really happy with
anyone that stick with us talking about testing for so long. Testing tends to
be a somewhat boring topic. It's interesting that we were able to extract so
much from it, and at least to me, it has been a very
valuable discussion. I really like some of the points that you brought up,
and it's also nice to see that you're testing it the same way as me
conceptually, so that gives me some more insight that, Okay, perhaps I'm
in the right track like other people that I didn't. You are doing the
same thing, So that's that's always good news. Before we start wrapping up,
I want to make sure that we haven't not touched on anything that you
consider to be super important. So my question to you is kind of like
a catch up question. Is there anything that you think is really relevant about
this subject of testing that I haven't asked, I haven't touched upon, but
you think we should talk about. Is there anything like that? Yeah,
there's two things. One is code coverage and the other is clean code.
So code coverage I mean the percentage of you know, the main applications code
that has been covered by tests. A lot of times you'll meet people that
want one hundred percent code coverage, which is a lot of times ridiculos,
right, because especially in the Java world, you have what we call POJOs
or plain old Java objects, and they're just an object with getters and setters,
right, and there's there's not much reason to test those because you know
they're going to work, right, And so I think test coverage a lot
of times. I think seventy to eighty percent is a good goal, and
and beyond that you're probably just you know, writing meaningless tests that really don't
do much. But boost your test coverage and so that's what we kind of
aim for in Jay Hipster is you know, between seventy and eighty percent also
clean code. The reason I mentioned that is we use Sonar to test the
sample apps that we can generate and verify that there isn't security issues or just
you know known things in type script or JavaScript or Java that you might do.
And so Sonar and Sonar Cube is very useful for that can run in
a doctor container if you want to do it locally, but we use Sonar
Cloud and it basically we fix issues between every release because we get these alerts
say hey, this code might have vulnerabilities or might have issues, and so
I think, you know, not being so focused on testing it at forever
release, but it's just handy to know that you can improve your code with
tools like that. Nice, nice, great additions. Thank you. Yeah,
so now let's start wrapping up. Matt, I would love to let
you do the first round of promos. So that's just a section in the
show where we shamelessly plug whatever we're working on or things that we would like
people to be aware of. So what would you like to promote? So
I'm on GitHub at m rabel m r ai b l E and that's where
you can find my ng demo app. Another one that's that's popular on there
is my Ja Hipster eight dash Demo, which is just a tutorial where I
show you how to get started with Jay Hipster and then I'll so twenty one
Points is another repo that is part of my Ja Hipster minibook, and that's
a full stack app that shows you how to basically monitor your health. It's
built with Angular and spring Boot and you basically get three points a day for
eating well, not drinking, and exercising, so you can get twenty one
points in a week. So that was a fun sample app that I created
that you can not only find at twenty one dash points dot com, but
also you could clone it from GitHub and use it that way. I'm also
amorable on LinkedIn, Twitter, pretty much everywhere. Awesome. Okay, I'm
just going to plug the two companies that produce the show, so Top and
Dove's and Onvoid. If you're looking for more content about software development. Top
and Doves has several podcasts, so you can check out some of the other
shows that they have about React develops, machine learning. There's a lot of
topics that might be interesting for different sub inside software engineering, and if you're
a company or an individual that knows someone that wants help to build their product,
so definitely check out Onvoid dot com. This is U N Void dot
com and they are basically a software and design consultancy, so they can you
can outsource your software and development services to them. But what makes them different
from other companies that do the same is that whereas with other companies, you
would pay by the hour and then the professionals are incentivized to take up longer
to deliver the tests, with Onvoid, you actually only pay after the tasks
are delivered and approved, so you have predictability on your costs and on your
quality because you know beforehand how much each thing is going to cost, and
you also know that this thing is going to be up to your quality standards.
Otherwise they're not going to approve and they're not going to get paid.
So it's a very interesting model that puts all the risk to their side and
leaves the client happy to sleep at night knowing that everything is going to be
on track in terms of quality and budget. So yeah, definitely check out
you and Void dot com if you're interested in that. Again, thank you
so much for sticking with us up until the end. I hope you have
a great week. Matt, thank you so much for being with us and
I will see you in the next week.