1
00:00:05,280 --> 00:00:09,839
Hey, Welcome to Adventures in Angler, the podcast where we keep you updated

2
00:00:09,880 --> 00:00:14,560
on all things Angular related. This
show is produced by two companies, Top

3
00:00:14,599 --> 00:00:18,359
and Doves and Onvoid. Top and
Doves is where we create top and devs.

4
00:00:18,399 --> 00:00:22,359
We get top and pay in recognition
but working on interesting problems and making

5
00:00:22,440 --> 00:00:28,679
meaningful community contributions. And Void provides
remote design and software development services on a

6
00:00:28,760 --> 00:00:34,359
task basis, so clients only pay
after the tasks are delivered and approved.

7
00:00:35,000 --> 00:00:41,960
In today's episode, we will talk
about ng demo and just overall testing practices

8
00:00:42,119 --> 00:00:47,119
on Angular applications. My name is
Lucas Paganini. I'm your host and a

9
00:00:47,159 --> 00:00:52,320
podcast and joining me in today's episode
is a very special guest, Matt.

10
00:00:53,840 --> 00:00:57,359
Matt, let me know if I
butcher your surname, but I believe it

11
00:00:57,399 --> 00:01:03,320
would be pronounced rabel. Is that
that's correct? Awesome? Awesome, got

12
00:01:03,320 --> 00:01:07,280
it right? Nice? So.
Matt is a web developer and author of

13
00:01:07,480 --> 00:01:12,280
the Angular Minibook, a practical guide
to developing apps with Angular and springbook,

14
00:01:12,799 --> 00:01:19,719
and as part of the of this
book and the content that he produces,

15
00:01:19,040 --> 00:01:25,640
he created well. He has a
repository which is called Angie Demo and it's

16
00:01:25,640 --> 00:01:32,400
a demo application using some of the
latest versions of Angular, and he also

17
00:01:32,879 --> 00:01:38,920
set up testing automated testing in this
repository. So what we're going to try

18
00:01:38,959 --> 00:01:44,640
to talk about more in here is
how did he set up automated testing in

19
00:01:44,680 --> 00:01:49,719
this repository and some of the different
ways in which Angular developers are doing testing

20
00:01:49,760 --> 00:01:55,159
nowadays, because we have the native
Angular modules for doing testing, but we

21
00:01:55,200 --> 00:02:00,000
also have Cyprus, we have Playwright, we even have Storybooks still that allows

22
00:02:00,079 --> 00:02:05,760
us to test individual components, and
there are some other companies and tools such

23
00:02:05,760 --> 00:02:09,360
as apply Tools. So this is
kind of the overall introu for those of

24
00:02:09,360 --> 00:02:14,400
you that might be interested, stick
to it, and we're going to start

25
00:02:15,240 --> 00:02:21,319
going deeper into that topic now.
So Matt, just so that we can

26
00:02:21,800 --> 00:02:24,400
start out, first off, thank
you for taking the time to be here

27
00:02:24,599 --> 00:02:30,639
in the show. I really appreciate
you you being here. And let's just

28
00:02:31,159 --> 00:02:39,560
give people an introduction on how things
are structured on Engie Demo in terms of

29
00:02:39,680 --> 00:02:46,759
automated testing. So in NGI demo, it basically just has unit tests for

30
00:02:46,960 --> 00:02:53,240
components and they're they're very simple,
right They They basically don't really do much

31
00:02:53,240 --> 00:02:59,120
accept verify that the component's been instantiated, right, but that's very helpful to

32
00:02:59,240 --> 00:03:04,639
know if any errors in your component. And then there is a service test

33
00:03:04,719 --> 00:03:07,680
as well, because there's basically a
service that calls out to get like a

34
00:03:07,759 --> 00:03:12,520
list of people that are rendered in
the UI, and so in that test

35
00:03:12,560 --> 00:03:17,680
there's more like mocking that happens,
right of like the HTTP request and verifying

36
00:03:17,719 --> 00:03:22,159
you know that certain data comes back. And then there's also end to end

37
00:03:22,199 --> 00:03:25,479
tests which are driven with Cyprus and
for the most part, you know,

38
00:03:25,560 --> 00:03:31,240
the the ng demo app is very
boring or simple, right because I call

39
00:03:31,280 --> 00:03:38,240
it like the bare bones basically Angular
app, regular tutorial and Cypress is just

40
00:03:38,360 --> 00:03:43,520
verifying that the functionality works. Right. It has a list screen of happens

41
00:03:43,560 --> 00:03:46,319
to be Denver Nuggets players you know
in the NBA, and you can you

42
00:03:46,319 --> 00:03:51,039
know, click on them and edit
them or you can add a new one

43
00:03:51,560 --> 00:03:53,360
and that's it. And it's just
talking to a Jason file. It uses

44
00:03:53,439 --> 00:03:59,639
like in memory storage, so it's
not talking to an actual database versus like

45
00:03:59,680 --> 00:04:03,240
the Angular minibook shows you how to
talk to an Angular data or a database

46
00:04:03,240 --> 00:04:10,479
in the back end with spring boob
and so that Cyprus test is very simple,

47
00:04:10,479 --> 00:04:14,800
but there's also GitHub actions that show
how you can automate it with CI.

48
00:04:15,240 --> 00:04:19,199
And then there's there's different branches for
Angular material. There's one for Bootstrap,

49
00:04:19,279 --> 00:04:21,600
there's one for US zero, and
there's one for electron. So it

50
00:04:21,680 --> 00:04:26,160
kind of you know, verifies like
with a zero that you can actually log

51
00:04:26,240 --> 00:04:29,639
in right to an application. And
so you know, a lot of that's

52
00:04:29,800 --> 00:04:32,839
just to show you the bare bones
that you need for testing infrastructure. Awesome,

53
00:04:32,959 --> 00:04:38,560
awesome, Okay, Well, one
thing that I think we can get,

54
00:04:39,199 --> 00:04:45,000
we can create a distinction for people
just to get started on this discussion

55
00:04:45,199 --> 00:04:49,120
is the different types of things that
we're going to be testing right, Because

56
00:04:49,240 --> 00:04:56,839
if you're just testing logic, like
for example, pure functions, then my

57
00:04:57,040 --> 00:05:01,319
approach is always going to be just
right in regular unit tests, and that

58
00:05:01,319 --> 00:05:05,519
can be with Jasmine, that can
be with Jest. I don't care like

59
00:05:05,639 --> 00:05:12,160
whatever comes with the framework that I'm
using. So I know that nowadays it's

60
00:05:12,279 --> 00:05:16,439
much easier to use Jest with Angular
and Acts for example, allows you to

61
00:05:16,560 --> 00:05:23,439
very easily run Angular tests using Jests
instead of Jasmine, which used to be

62
00:05:23,519 --> 00:05:28,759
the default test runner for Angler.
So nowadays we have this this option.

63
00:05:28,959 --> 00:05:33,720
But if you're using Jasmine or JEST, I really wouldn't mind because their syntax

64
00:05:33,839 --> 00:05:39,360
is pretty much the same and they
do the same thing. So if you're

65
00:05:39,399 --> 00:05:46,639
just going to test pieces of your
logic, so for example, function acts

66
00:05:46,759 --> 00:05:51,399
should receive those arguments and return that
value, then just write regular unit tests,

67
00:05:51,480 --> 00:05:57,639
don't even bother with the framework.
So try, at least myself,

68
00:05:58,000 --> 00:06:03,519
I try to isolate the parts of
my application that are not framework specific and

69
00:06:03,839 --> 00:06:09,480
really make them not framework specific,
you know, like everything that is just

70
00:06:09,519 --> 00:06:14,079
a business logic. I try to
not make it too coupled with Angular and

71
00:06:14,319 --> 00:06:23,399
just have regular pure functions that declare
this business logic and just test those individual

72
00:06:23,519 --> 00:06:28,879
units. But then for anything that
requires me to interact with the front end,

73
00:06:29,439 --> 00:06:32,680
then I'm not going to shy away
from using Angular. And in those

74
00:06:32,720 --> 00:06:38,480
scenarios that would become a service.
Right, So that's either going to be

75
00:06:38,480 --> 00:06:43,920
a service or an injectable function,
right, So a function that runs within

76
00:06:44,600 --> 00:06:51,399
an injection context in Angular and in
such scenarios, then I would still write

77
00:06:51,439 --> 00:06:57,199
a regular JEST or adjustment test,
but then of course I would have to

78
00:06:59,000 --> 00:07:05,199
use the test bad from Angular so
that I can declare the service as a

79
00:07:05,240 --> 00:07:11,360
provider in there, and then I
can get an instance of the service to

80
00:07:11,519 --> 00:07:15,720
run tests against it, so that
would be the only difference. But when

81
00:07:15,720 --> 00:07:21,800
it comes to visual testing, so
when it comes to actually testing a component,

82
00:07:23,279 --> 00:07:27,360
for example, an accordion, So
let's say that when you click on

83
00:07:27,439 --> 00:07:30,560
the tuggle, it should expand and
show the main content of the accordion,

84
00:07:30,839 --> 00:07:34,839
and when you click on the head
again it should collapse. For those things,

85
00:07:35,079 --> 00:07:42,959
my current approach is to not write
angular tests for that, and what

86
00:07:43,000 --> 00:07:49,040
I would rather do is just write
an end to end test for the main

87
00:07:50,120 --> 00:07:57,240
crucial clows of the application, and
I would do that using either Cyprus or

88
00:07:57,279 --> 00:08:01,759
Playwright. So I would not be
testing the accordion itself. I would not

89
00:08:01,879 --> 00:08:07,240
be testing that the accordion expands and
collapses. I would just be testing a

90
00:08:07,319 --> 00:08:11,079
flow that perhaps uses the accordium,
so it would be tested as a byproduct,

91
00:08:13,199 --> 00:08:16,240
but the test wouldn't be about the
accordium. It would be about a

92
00:08:16,399 --> 00:08:22,279
user flow that just happens to use
the accordium. Right. So the downside

93
00:08:22,319 --> 00:08:28,079
of that is that I have less
coverage of my components because I'm not really

94
00:08:28,120 --> 00:08:31,799
testing all the different things that the
accordium component could do. But the good

95
00:08:31,799 --> 00:08:37,240
thing about this is that I'm testing
what actually matters to the users, right,

96
00:08:37,279 --> 00:08:41,759
which is that they are able to
complete their actions. So there's a

97
00:08:41,840 --> 00:08:46,279
downside there, but to me it
just feels faster. It felt that all

98
00:08:46,360 --> 00:08:52,840
the times in the past that I
try to write component tests in Angular,

99
00:08:54,679 --> 00:09:00,679
like using the test bad, instantiating
the component, simulating interacts, you know,

100
00:09:00,759 --> 00:09:05,759
like colicking on the head and seeing
if the content appears, I think

101
00:09:05,799 --> 00:09:13,320
that it didn't felt natural. I
wasn't really testing it how the users would

102
00:09:13,320 --> 00:09:18,000
test it. So these are the
ways in which I'm approaching testing currently.

103
00:09:18,799 --> 00:09:24,360
I would be very curious to know
how you're approaching it conceptually. So just

104
00:09:24,399 --> 00:09:31,159
to summarize, I separate the things
that I test between functionality and presentation.

105
00:09:31,600 --> 00:09:35,559
For functionality, if I can make
it as simple as a pure function,

106
00:09:35,720 --> 00:09:39,360
then that's what's going to be,
and then I just use jest or Jallesman

107
00:09:39,440 --> 00:09:45,360
to test it. If I really
need the Angular framework, then I turn

108
00:09:45,440 --> 00:09:48,960
it into a service or an injectable
function, and then I use the Angular

109
00:09:48,039 --> 00:09:54,120
test bad to provide and instantiate that
in order for me to test. And

110
00:09:54,200 --> 00:09:58,720
that's the logic side of things.
Whenever I create something for presentation, so

111
00:10:00,039 --> 00:10:05,639
an actual component, then I'm not
currently writing unit tests for those components.

112
00:10:05,960 --> 00:10:11,039
What I do is I just write
end to end tests with either Cybers or

113
00:10:11,039 --> 00:10:16,120
Playwright that test flows in which that
component might or might not be used.

114
00:10:16,000 --> 00:10:20,159
But yeah, how do you approach
this? Match? But I think your

115
00:10:20,200 --> 00:10:24,080
approach is correct because a lot of
times unit tests should be testing logic,

116
00:10:24,159 --> 00:10:26,840
right, and if you have components
that just don't have a lot of logic

117
00:10:26,879 --> 00:10:31,360
in it, then you're probably writing
unit tests to test the framework. And

118
00:10:31,399 --> 00:10:35,799
if you're using a framework, you
should pretty much trust that that framework works,

119
00:10:35,240 --> 00:10:39,879
right, And so I think your
approach is good there. I think

120
00:10:39,159 --> 00:10:43,759
the beauty of end to end tests
is they can be used for your app,

121
00:10:45,080 --> 00:10:48,440
especially if you're migrating from one thing
to another. I know, you

122
00:10:48,480 --> 00:10:52,159
know, thought Works has had a
lot of consulting around micro front ends and

123
00:10:52,840 --> 00:10:56,600
migrating from Angular JS to like react, right, so just a portion of

124
00:10:56,600 --> 00:11:00,720
the page has like React on it, or maybe it has you know,

125
00:11:01,159 --> 00:11:03,960
the new version of Angular instead of
Angular jass. So by having those end

126
00:11:05,039 --> 00:11:07,759
to end tests, you can help
migrate, you know, from one framework

127
00:11:07,799 --> 00:11:11,039
to another or one concept to another. And it's not just you know,

128
00:11:11,200 --> 00:11:18,000
verifying that the UI comes up correctly. And so jay Hipster is a project

129
00:11:18,000 --> 00:11:20,480
that I work on, an open
source project that we use just instead of

130
00:11:20,559 --> 00:11:24,799
Jasmine, and Jasmine is used in
my ENNG demo because it's just bare bones,

131
00:11:24,879 --> 00:11:28,840
right, I'm not trying to use
anything, you know, outside of

132
00:11:28,080 --> 00:11:35,960
Angular, and we have like seventy
coverage on all the components, but we're

133
00:11:35,000 --> 00:11:39,600
also generating the code, right,
so when you generate code, you want

134
00:11:39,639 --> 00:11:43,519
to make sure that they're tested well, and so that one is a bit

135
00:11:43,559 --> 00:11:46,720
more unit test heavy. But if
you look at the components in there,

136
00:11:46,120 --> 00:11:50,879
there's a bit more logic in them
than my bare bones example. And then

137
00:11:50,120 --> 00:11:54,679
as far as like end to end
tests, I think it's good to have

138
00:11:54,759 --> 00:11:58,799
CI that's verifying everything works. But
I've spent a lot of times in my

139
00:11:58,919 --> 00:12:03,559
career like babysitting SEEI I call it
because it has false positives. And in

140
00:12:03,559 --> 00:12:07,360
fact, on the jay Hipster project, when we were using Protractor before Cypress

141
00:12:07,399 --> 00:12:11,559
existed, we would have failures all
the time that you couldn't reproduce locally,

142
00:12:13,120 --> 00:12:18,159
and so we basically saw a protractor
as a burden, right, and migrating

143
00:12:18,159 --> 00:12:22,320
to Cypress really helped us a lot. But I think you know, front

144
00:12:22,399 --> 00:12:26,879
end developers typically don't write as many
tests in my experience as back end developers.

145
00:12:26,519 --> 00:12:31,279
But I think what you need to
remember is that if you're not writing

146
00:12:31,320 --> 00:12:35,679
tests, you're just not automating things
that you're doing already, because as a

147
00:12:35,679 --> 00:12:41,200
front end developer, you'll be testing
out the UI all day manually, and

148
00:12:41,240 --> 00:12:43,279
you can really speed up your workflow
if you use you know, end to

149
00:12:43,360 --> 00:12:48,720
end tests or something similar to basically
automate it. But it's never going to

150
00:12:48,720 --> 00:12:54,000
replace like the visual kind of testing, right because one experience that we had

151
00:12:54,039 --> 00:12:58,320
in Jay Hipster was, you know, we upgrade the the latest version of

152
00:12:58,320 --> 00:13:01,200
Bootstrap and all of a sudden,
like the red buttons and the blue buttons

153
00:13:01,200 --> 00:13:05,840
had black text on them, and
our CI would have never caught that,

154
00:13:05,320 --> 00:13:09,000
right because we're not getting that to
a granular level. And then we found

155
00:13:09,000 --> 00:13:13,240
out we had a stylishoot that was
overriding the default of white text on a

156
00:13:13,279 --> 00:13:16,600
you know, blue background. So
I still think even though and the N

157
00:13:16,679 --> 00:13:22,480
tests are great, you still kind
of want maybe a human involved or some

158
00:13:22,480 --> 00:13:26,000
sort of visual testing frame involved.
Gotcha. Yeah, That's that's a very

159
00:13:26,000 --> 00:13:31,240
good point. Is if you're testing
components the same way that you're testing logic,

160
00:13:31,840 --> 00:13:39,519
then you're not gonna you're not gonna
see right, Like you're literally not

161
00:13:39,799 --> 00:13:43,440
seeing what the component is doing.
And thus if a color changes, or

162
00:13:43,519 --> 00:13:48,960
if something is rendered in a different
position as where it should be, then

163
00:13:48,000 --> 00:13:54,480
your test is probably not going to
get that. You could write a test

164
00:13:54,840 --> 00:14:00,080
using protractor or or something like that
to test this, I guess, but

165
00:14:00,440 --> 00:14:07,799
it would be more effort then using
tools that have visual regression tests. And

166
00:14:07,840 --> 00:14:11,879
that's where we start leaning on some
of the solutions that exist nowadays to facilitate

167
00:14:11,919 --> 00:14:18,399
component testing, which, to be
perfectly clear, I have not explored long

168
00:14:18,559 --> 00:14:22,240
enough to tell the audience like,
oh, hey, I tried this and

169
00:14:22,279 --> 00:14:24,399
you can go this direction. So
I really don't know, but I think

170
00:14:24,440 --> 00:14:30,080
it's interesting for us to at least
tell the audience what exists nowadays. Right,

171
00:14:30,159 --> 00:14:35,759
So, I know that Cypress component
testing is a very easy option nowadays.

172
00:14:37,039 --> 00:14:41,879
They even have native support for Angular
components. So if you go to

173
00:14:43,519 --> 00:14:48,320
the Cypress docs and you go to
component testing, there's an overview there with

174
00:14:48,399 --> 00:14:52,720
a very basic example of how you
would test an Angular component, and it's

175
00:14:52,799 --> 00:14:58,200
just so easy to follow along with
the test implementation, really very easy to

176
00:14:58,279 --> 00:15:03,159
understand how the test is written and
what it's doing, what it's testing.

177
00:15:03,519 --> 00:15:09,639
So Cyprus does seems to be getting
this right at least when you look at

178
00:15:09,639 --> 00:15:13,919
the docs. Right when you actually
start writing the tests, maybe it becomes

179
00:15:15,120 --> 00:15:22,360
more complicated than how it looks in
this very simple example in here. But

180
00:15:22,159 --> 00:15:28,279
it's nice that they do have an
API dedicated for testing components, and they

181
00:15:28,320 --> 00:15:35,720
already have native support for Angler.
But then we also have a very established

182
00:15:35,960 --> 00:15:46,000
alternative already for component testing, and
not just component testing but just but also

183
00:15:46,759 --> 00:15:54,799
how can I say the point are
previewing components, right, which is Storybook.

184
00:15:56,000 --> 00:16:00,840
So it's been a while since people
talk about Storybook. It's not a

185
00:16:00,879 --> 00:16:07,039
hot topic anymore. It was a
few years ago. But Storybook already has

186
00:16:07,080 --> 00:16:12,440
a test runner, and with their
test runner, you can do interaction tests,

187
00:16:12,559 --> 00:16:17,480
you can do accessibility tests, you
can do visibility tests, and that

188
00:16:17,639 --> 00:16:25,519
all comes with a tool which was
already designed specifically for dealing with individual components.

189
00:16:25,679 --> 00:16:30,559
Right, So by using Storybook,
you also get that nice application that

190
00:16:30,600 --> 00:16:34,799
you can deploy and allow your designers
to play around with the components to see

191
00:16:34,799 --> 00:16:41,279
if it's how they envision them.
So that's definitely a tool that I would

192
00:16:41,320 --> 00:16:45,320
also consider, because it seems that
it was built specifically for this, whereas

193
00:16:45,399 --> 00:16:51,120
Cyprus wasn't really built for components,
right, it was built for end end

194
00:16:51,200 --> 00:16:56,720
tests, and now they are also
allowing us to use it to test components,

195
00:16:56,759 --> 00:17:02,600
but originally wasn't built for this.
I wonder, Matt, have you

196
00:17:02,639 --> 00:17:08,359
ever explored some of those options.
Maybe you have others that you you know

197
00:17:08,440 --> 00:17:12,400
that exist that we could at least
how at the audience so that can research

198
00:17:12,480 --> 00:17:18,079
more. But I have heard a
storybook and I've you know, helped like

199
00:17:18,279 --> 00:17:22,559
edit and published blog posts about it
at my previous job. But also it

200
00:17:22,359 --> 00:17:26,319
was also in a React context,
so until today I wasn't even aware that

201
00:17:26,319 --> 00:17:29,920
you could use it with other frameworks. But I also think a lot of

202
00:17:29,960 --> 00:17:34,160
times the reason we might not be
using something like storybook is a lot of

203
00:17:34,160 --> 00:17:40,279
times I'm developing apps right and testing
apps, I'm not developing components in testing

204
00:17:40,319 --> 00:17:44,160
components. Like I think if you're
a company that has a component library,

205
00:17:44,640 --> 00:17:48,519
you might be using Storybook more because
you have designers that are like interacting with

206
00:17:48,559 --> 00:17:52,680
that library and trying to make it
work. But I think what you've seen

207
00:17:52,759 --> 00:17:56,440
in the Angular ecosystem is a lot
of libraries are open source as well,

208
00:17:56,880 --> 00:18:00,920
right, and so it's typically a
small team of developers trying to make something

209
00:18:00,920 --> 00:18:06,440
happen. It's not more established like
a company would be with a design system

210
00:18:06,480 --> 00:18:10,799
and you know docs that document how
everything works and use you know, something

211
00:18:10,880 --> 00:18:15,559
like storybook and it's testing feature to
verify everything works. I think that's that's

212
00:18:15,599 --> 00:18:18,920
a more formal system, and as
developers are more used to just you know,

213
00:18:19,039 --> 00:18:22,359
getting down and dirty with the code
and making it work that way,

214
00:18:22,680 --> 00:18:29,400
especially with app development versus component like
library development. Yeah, that does make

215
00:18:29,480 --> 00:18:36,640
sense. I also didn't you that
Storybook work with other frameworks until a few

216
00:18:36,640 --> 00:18:41,480
months ago when I decided to.
Well, actually it was because I saw

217
00:18:41,519 --> 00:18:48,119
that NX had an add on for
it, and NX was originally created in

218
00:18:48,160 --> 00:18:52,000
a very Angular centric context, so
I just thought it was interesting when I

219
00:18:52,039 --> 00:18:57,000
saw Storybook inside NX, and then
I saw that they actually do support other

220
00:18:57,079 --> 00:19:03,599
frameworks. They actually support not just
React and Angular, but many others,

221
00:19:03,640 --> 00:19:08,559
like if you just go to their
website now I believe that they support View

222
00:19:08,799 --> 00:19:15,759
as well. Yep, so React, View, Angular, Svelt as well.

223
00:19:15,680 --> 00:19:23,680
So that's pretty pretty interesting. Seems
that they really expanded their support even

224
00:19:23,799 --> 00:19:30,720
native web components is something that they
are also they're also supporting at this point,

225
00:19:30,039 --> 00:19:33,799
which is pretty cool. I was
going to ask about Spelt because you

226
00:19:33,799 --> 00:19:38,319
know, I'm primarily a Java developer
most of my days, right, and

227
00:19:38,359 --> 00:19:42,680
I also am one of the few
Java champions that likes JavaScript and Typescript,

228
00:19:44,240 --> 00:19:51,000
and so it's very interesting for me
that in the JavaScript world we have Angular,

229
00:19:51,079 --> 00:19:53,559
React, View, and Spelt,
and they've been around for almost a

230
00:19:53,599 --> 00:19:56,880
decade now, right, But in
the Java world maybe it's the same.

231
00:19:56,880 --> 00:20:00,839
In the dot net world, there's
always joe about a new JavaScript framework,

232
00:20:02,200 --> 00:20:04,400
you know, every week or every
day or whatnot, and it really hasn't

233
00:20:04,440 --> 00:20:07,920
happened for a long time. So
it's funny that those jokes still exist and

234
00:20:07,960 --> 00:20:12,559
that perception still exists when it's not
really true. Yep, yeah, that's

235
00:20:12,599 --> 00:20:17,759
true. I'm really amazed at the
amount of tools that a few years ago

236
00:20:17,880 --> 00:20:22,039
only existed for React, and slowly
they are expanding to work with other frameworks

237
00:20:22,079 --> 00:20:27,759
as well. It's really nice to
see that we from the Angular community are

238
00:20:27,799 --> 00:20:33,839
getting support from more tools. Still, there are lots of things that I

239
00:20:33,960 --> 00:20:41,039
wish existed an Angular that are currently
just React specific. So just one quick

240
00:20:41,079 --> 00:20:48,599
example that comes to mind is Radish
radix uy. It's a headless components that

241
00:20:48,680 --> 00:20:55,440
you can style and it really saves
a bunch of time. So there there

242
00:20:55,480 --> 00:21:00,920
are some things like it for Angular, but there isn't a Radix implementation.

243
00:21:00,759 --> 00:21:08,240
And also I think Framer is a
design tool which is similar to Figma,

244
00:21:08,799 --> 00:21:14,039
and as far as as I'm aware, it allows you to drag and drop

245
00:21:14,440 --> 00:21:19,680
React components into it, but it
doesn't work with other types of frameworks,

246
00:21:19,720 --> 00:21:26,359
only React components. Well, I
wouldn't be surprised if there is more support

247
00:21:26,440 --> 00:21:30,200
from these tools for Angular because there's
kind of an Angular renaissance happening now right

248
00:21:30,240 --> 00:21:34,640
where it's adding more features. It's
not just upgrading and becoming faster. And

249
00:21:34,720 --> 00:21:38,920
now there's even the talk of combining
with wiz right, like that's happening at

250
00:21:38,920 --> 00:21:42,680
Google, which is what I think
powers YouTube or something like that. So

251
00:21:42,680 --> 00:21:48,640
it's more performance based, and so
I think you will see Angular get faster.

252
00:21:48,839 --> 00:21:52,720
And then React isn't really a framework, it's just a UI kind of

253
00:21:52,400 --> 00:21:56,880
you know framework, right, It's
you have to pull in reducts and everything

254
00:21:56,880 --> 00:22:00,559
else to like make it a full
on frame. So I wouldn't be surprised

255
00:22:00,599 --> 00:22:03,759
if for the next few years,
right, like, Angular starts to be

256
00:22:04,039 --> 00:22:08,319
more popular, and a lot of
that's because, you know, we're getting

257
00:22:08,319 --> 00:22:14,480
newcomers into the field and they don't
have this legacy of one is better than

258
00:22:14,519 --> 00:22:15,640
the other. They just want to
learn something and get a good job,

259
00:22:15,680 --> 00:22:25,519
you know. Yeah, definitely,
definitely interesting interesting. Okay, So currently

260
00:22:25,839 --> 00:22:32,240
just recapping if you were nowadays to
start an application from scratch, an Angular

261
00:22:32,279 --> 00:22:41,680
application, what would you explore in
terms of tools for testing? Would you

262
00:22:41,720 --> 00:22:45,240
so end to end for example,
would you go straight to Cyprus or would

263
00:22:45,279 --> 00:22:51,079
you explore lay right. I heard
there's another one called Apply Tools. I'm

264
00:22:51,119 --> 00:22:56,359
not sure if it's end to end
or component testing, but I believe it's

265
00:22:56,079 --> 00:23:00,880
end to end. So most of
my experience with Apple Tools is just because

266
00:23:00,960 --> 00:23:03,200
I had someone to admire work there, which is Angie Jones. Now she's

267
00:23:03,240 --> 00:23:10,200
a TBD or block writer or cash
app like that whole company Square and all

268
00:23:10,200 --> 00:23:14,400
that. But I believe it was
a visual testing framework. So I tried

269
00:23:14,440 --> 00:23:18,319
to make it work on a blog
that we had that basically showed how you

270
00:23:18,319 --> 00:23:22,599
would, you know, use like
macros and stuff to spit out a bunch

271
00:23:22,640 --> 00:23:26,480
of instructions on how to like log
into octa kind of thing, and so

272
00:23:27,000 --> 00:23:32,200
I wanted to basically verify that,
you know, if anyone changed these certain

273
00:23:32,240 --> 00:23:34,920
files, like all the instructions would
still render. So I believe app with

274
00:23:36,039 --> 00:23:37,960
tools is good at that. I
just never got it working right. But

275
00:23:38,000 --> 00:23:42,720
the whole point is like it will
notify you I visual regressions take place,

276
00:23:44,160 --> 00:23:47,519
and so as far as you're asking
about the tools, I would choose a

277
00:23:47,559 --> 00:23:49,720
lot of times, if it's a
full stack app, I would just use

278
00:23:49,759 --> 00:23:53,640
what jay Hipster has, right because
jay Hipster uses like just for unit testing,

279
00:23:53,759 --> 00:23:57,079
uses Cypress for inten tests, and
we've had a lot of luck with

280
00:23:57,119 --> 00:24:03,160
that using GitHub actions. And if
it's a view or React, we have

281
00:24:03,200 --> 00:24:07,880
support for that as well. So
as you know, primarily an Angular person,

282
00:24:07,160 --> 00:24:11,759
I can look if I'm on a
React project and see how jay Hipster's

283
00:24:11,799 --> 00:24:15,799
doing it. Like I don't have
to use ja Hipster for the the app.

284
00:24:15,880 --> 00:24:18,839
I can just generate apps with it
and see like the code it's generating.

285
00:24:18,920 --> 00:24:22,799
So that's that's very helpful. And
a lot of times, you know,

286
00:24:23,240 --> 00:24:29,240
people especially enterprises, aren't creating brand
new Angular apps right there. They

287
00:24:29,440 --> 00:24:33,640
have an existing app that they want
to replace part of right. So a

288
00:24:33,640 --> 00:24:37,440
lot of times you don't get like
the green field where you can pick all

289
00:24:37,440 --> 00:24:41,119
the different tools you might use.
I mean it might be, you know,

290
00:24:41,160 --> 00:24:45,240
there's a team that runs the back
end, and the back end is

291
00:24:45,640 --> 00:24:51,319
PHP or Java dot net, and
they choose Playwright because they have experience with

292
00:24:51,359 --> 00:24:53,200
that, and so you might not
get a choice to use Cyprus. Right,

293
00:24:53,240 --> 00:24:59,440
the corporate standard is Playwright. So
I think you kind of use what's

294
00:24:59,480 --> 00:25:02,519
available depending on the project. Now, if you're developing your own thing,

295
00:25:02,559 --> 00:25:06,640
it's a whole different ballgame. Right, you get to choose, but you

296
00:25:06,680 --> 00:25:10,000
know a lot of times you will
end up with a team and then you

297
00:25:10,079 --> 00:25:12,920
might have to choose from that team's
expertise. As far as Playwright is concerned,

298
00:25:12,960 --> 00:25:17,599
I haven't actually used it. I
believe it's a Microsoft product, But

299
00:25:17,720 --> 00:25:21,279
we did have an issue in the
Jay Hipster project where people were like,

300
00:25:21,359 --> 00:25:25,119
let's explore this, let's compare it
to Cyprus, and let's implement it.

301
00:25:25,160 --> 00:25:27,920
So give our users a choice whether
they want to use Cypress or Playwright,

302
00:25:29,559 --> 00:25:32,200
and it basically never got off the
ground. So the main person that was

303
00:25:32,240 --> 00:25:34,279
interested in it never found the time. I don't know if they had small

304
00:25:34,319 --> 00:25:40,480
kids or whatnot, but you know
that often takes people's after hours. Gotcha.

305
00:25:40,720 --> 00:25:45,119
Gotcha? Okay, And by the
way, you mentioned j Hipster,

306
00:25:45,240 --> 00:25:51,480
but I don't think we gave a
description to the audience of what j hipster

307
00:25:51,720 --> 00:25:59,279
is. So jay Hipster started as
an Angular JS front end generator and back

308
00:25:59,400 --> 00:26:03,359
end was in and then spring boot
came along in twenty fourteen and we kind

309
00:26:03,359 --> 00:26:07,799
of adopted that. So and we've
kept up with Angular over the years.

310
00:26:07,839 --> 00:26:11,400
Right, So we started with Angular
JS and now it's on Angular seventeen and

311
00:26:11,480 --> 00:26:18,880
so it's it's basically an application generator, full stack APP and with springboot you

312
00:26:18,920 --> 00:26:22,400
can package it in a jar they
call it in Java, and so it's

313
00:26:22,440 --> 00:26:26,839
a single artifact that has your whole
application that can be running front end and

314
00:26:26,880 --> 00:26:30,359
Angular back end and spring boot.
And it can also do micro services and

315
00:26:30,400 --> 00:26:37,279
microfront ends. So if you want
to have multiple micro services spread out because

316
00:26:37,680 --> 00:26:40,880
you have different teams working on different
components, then you can do that.

317
00:26:40,920 --> 00:26:44,240
And the cool thing with microfront ends
is those front ends can be a part

318
00:26:44,279 --> 00:26:48,400
of that micro service and then there's
a gateway that has you a shell that

319
00:26:48,480 --> 00:26:55,920
pulls in all those microfront ends using
module Federation, and so it's a school

320
00:26:55,960 --> 00:26:57,720
project. It's been around for ten
years. I wrote a book on it.

321
00:26:59,279 --> 00:27:03,519
I will as like the lead security
engineer for the last six years,

322
00:27:03,519 --> 00:27:07,880
and I recently became like a project
lead. But that just means I'm doing

323
00:27:07,920 --> 00:27:11,680
releases now, so hopefully those will
happen more. But it's been a fun

324
00:27:11,799 --> 00:27:15,640
like way of showing people with the
cutting edges in Java land and you know,

325
00:27:15,720 --> 00:27:21,359
with the JavaScript frameworks. Yeah sure, cool, Okay, Okay,

326
00:27:22,440 --> 00:27:29,400
Matt, I think we can start
wrapping up the time went lying, but

327
00:27:29,680 --> 00:27:36,759
we're almost at thirty minutes of content
at this point. I'm really happy with

328
00:27:37,119 --> 00:27:41,799
anyone that stick with us talking about
testing for so long. Testing tends to

329
00:27:41,839 --> 00:27:48,799
be a somewhat boring topic. It's
interesting that we were able to extract so

330
00:27:48,920 --> 00:27:52,200
much from it, and at least
to me, it has been a very

331
00:27:52,279 --> 00:27:56,599
valuable discussion. I really like some
of the points that you brought up,

332
00:27:56,640 --> 00:28:00,000
and it's also nice to see that
you're testing it the same way as me

333
00:28:00,359 --> 00:28:04,519
conceptually, so that gives me some
more insight that, Okay, perhaps I'm

334
00:28:04,519 --> 00:28:08,759
in the right track like other people
that I didn't. You are doing the

335
00:28:08,799 --> 00:28:15,079
same thing, So that's that's always
good news. Before we start wrapping up,

336
00:28:15,160 --> 00:28:19,119
I want to make sure that we
haven't not touched on anything that you

337
00:28:19,200 --> 00:28:23,359
consider to be super important. So
my question to you is kind of like

338
00:28:23,400 --> 00:28:30,799
a catch up question. Is there
anything that you think is really relevant about

339
00:28:30,839 --> 00:28:36,480
this subject of testing that I haven't
asked, I haven't touched upon, but

340
00:28:37,079 --> 00:28:41,440
you think we should talk about.
Is there anything like that? Yeah,

341
00:28:41,480 --> 00:28:45,359
there's two things. One is code
coverage and the other is clean code.

342
00:28:45,720 --> 00:28:52,000
So code coverage I mean the percentage
of you know, the main applications code

343
00:28:52,079 --> 00:28:55,759
that has been covered by tests.
A lot of times you'll meet people that

344
00:28:56,200 --> 00:29:00,000
want one hundred percent code coverage,
which is a lot of times ridiculos,

345
00:29:00,240 --> 00:29:03,000
right, because especially in the Java
world, you have what we call POJOs

346
00:29:03,079 --> 00:29:07,720
or plain old Java objects, and
they're just an object with getters and setters,

347
00:29:07,759 --> 00:29:10,920
right, and there's there's not much
reason to test those because you know

348
00:29:10,960 --> 00:29:14,519
they're going to work, right,
And so I think test coverage a lot

349
00:29:14,519 --> 00:29:18,359
of times. I think seventy to
eighty percent is a good goal, and

350
00:29:18,359 --> 00:29:22,200
and beyond that you're probably just you
know, writing meaningless tests that really don't

351
00:29:22,200 --> 00:29:26,519
do much. But boost your test
coverage and so that's what we kind of

352
00:29:26,519 --> 00:29:30,279
aim for in Jay Hipster is you
know, between seventy and eighty percent also

353
00:29:30,400 --> 00:29:34,759
clean code. The reason I mentioned
that is we use Sonar to test the

354
00:29:34,839 --> 00:29:42,519
sample apps that we can generate and
verify that there isn't security issues or just

355
00:29:42,680 --> 00:29:48,160
you know known things in type script
or JavaScript or Java that you might do.

356
00:29:48,279 --> 00:29:53,079
And so Sonar and Sonar Cube is
very useful for that can run in

357
00:29:53,119 --> 00:29:56,839
a doctor container if you want to
do it locally, but we use Sonar

358
00:29:56,920 --> 00:30:02,920
Cloud and it basically we fix issues
between every release because we get these alerts

359
00:30:02,960 --> 00:30:07,960
say hey, this code might have
vulnerabilities or might have issues, and so

360
00:30:07,039 --> 00:30:12,079
I think, you know, not
being so focused on testing it at forever

361
00:30:12,160 --> 00:30:15,559
release, but it's just handy to
know that you can improve your code with

362
00:30:15,599 --> 00:30:22,000
tools like that. Nice, nice, great additions. Thank you. Yeah,

363
00:30:22,039 --> 00:30:26,759
so now let's start wrapping up.
Matt, I would love to let

364
00:30:26,799 --> 00:30:30,079
you do the first round of promos. So that's just a section in the

365
00:30:30,119 --> 00:30:36,799
show where we shamelessly plug whatever we're
working on or things that we would like

366
00:30:37,240 --> 00:30:44,519
people to be aware of. So
what would you like to promote? So

367
00:30:44,839 --> 00:30:48,559
I'm on GitHub at m rabel m
r ai b l E and that's where

368
00:30:48,559 --> 00:30:52,480
you can find my ng demo app. Another one that's that's popular on there

369
00:30:52,559 --> 00:30:56,279
is my Ja Hipster eight dash Demo, which is just a tutorial where I

370
00:30:56,319 --> 00:31:00,759
show you how to get started with
Jay Hipster and then I'll so twenty one

371
00:31:00,799 --> 00:31:04,319
Points is another repo that is part
of my Ja Hipster minibook, and that's

372
00:31:04,359 --> 00:31:08,960
a full stack app that shows you
how to basically monitor your health. It's

373
00:31:08,960 --> 00:31:15,200
built with Angular and spring Boot and
you basically get three points a day for

374
00:31:15,880 --> 00:31:18,839
eating well, not drinking, and
exercising, so you can get twenty one

375
00:31:18,839 --> 00:31:22,319
points in a week. So that
was a fun sample app that I created

376
00:31:22,359 --> 00:31:26,599
that you can not only find at
twenty one dash points dot com, but

377
00:31:26,680 --> 00:31:30,880
also you could clone it from GitHub
and use it that way. I'm also

378
00:31:30,960 --> 00:31:40,359
amorable on LinkedIn, Twitter, pretty
much everywhere. Awesome. Okay, I'm

379
00:31:40,400 --> 00:31:42,559
just going to plug the two companies
that produce the show, so Top and

380
00:31:42,640 --> 00:31:48,319
Dove's and Onvoid. If you're looking
for more content about software development. Top

381
00:31:48,359 --> 00:31:52,039
and Doves has several podcasts, so
you can check out some of the other

382
00:31:52,079 --> 00:31:56,880
shows that they have about React develops, machine learning. There's a lot of

383
00:31:56,920 --> 00:32:02,279
topics that might be interesting for different
sub inside software engineering, and if you're

384
00:32:02,279 --> 00:32:09,000
a company or an individual that knows
someone that wants help to build their product,

385
00:32:09,400 --> 00:32:15,240
so definitely check out Onvoid dot com. This is U N Void dot

386
00:32:15,279 --> 00:32:21,519
com and they are basically a software
and design consultancy, so they can you

387
00:32:21,559 --> 00:32:24,759
can outsource your software and development services
to them. But what makes them different

388
00:32:24,799 --> 00:32:30,640
from other companies that do the same
is that whereas with other companies, you

389
00:32:30,680 --> 00:32:35,640
would pay by the hour and then
the professionals are incentivized to take up longer

390
00:32:35,720 --> 00:32:39,599
to deliver the tests, with Onvoid, you actually only pay after the tasks

391
00:32:39,640 --> 00:32:45,240
are delivered and approved, so you
have predictability on your costs and on your

392
00:32:45,359 --> 00:32:50,200
quality because you know beforehand how much
each thing is going to cost, and

393
00:32:50,240 --> 00:32:52,799
you also know that this thing is
going to be up to your quality standards.

394
00:32:52,880 --> 00:32:55,519
Otherwise they're not going to approve and
they're not going to get paid.

395
00:32:55,720 --> 00:33:00,960
So it's a very interesting model that
puts all the risk to their side and

396
00:33:01,079 --> 00:33:07,359
leaves the client happy to sleep at
night knowing that everything is going to be

397
00:33:07,359 --> 00:33:10,240
on track in terms of quality and
budget. So yeah, definitely check out

398
00:33:10,359 --> 00:33:15,720
you and Void dot com if you're
interested in that. Again, thank you

399
00:33:15,799 --> 00:33:20,160
so much for sticking with us up
until the end. I hope you have

400
00:33:20,240 --> 00:33:22,920
a great week. Matt, thank
you so much for being with us and

401
00:33:23,039 --> 00:33:24,799
I will see you in the next
week.