WEBVTT
00:00:08.740 --> 00:00:09.240
[Speaker 0]: Do we have any listeners?
00:00:13.340 --> 00:00:13.840
It's you and I. I have a question.
00:00:16.420 --> 00:00:16.640
How many tests do you have for hyperbole and
00:00:18.800 --> 00:00:19.279
How would you rate the test coverage compared
00:00:21.279 --> 00:00:21.500
to other packages? Well,
00:00:28.279 --> 00:00:28.700
that's a tricky 1. Shall I spell it out loud
00:00:31.100 --> 00:00:31.600
and then maybe type it at the same time?
00:00:36.420 --> 00:00:36.920
So, I believe it's around like more than 300
00:00:43.660 --> 00:00:44.059
test cases now. But I cannot compare the test
00:00:45.220 --> 00:00:45.720
coverage to any other
00:01:00.020 --> 00:01:00.520
other package. Maybe I can type that later.
00:01:01.560 --> 00:01:02.060
What do you say, Badal?
00:01:02.660 --> 00:01:02.900
[Speaker 1]: package. I have no knowledge of any Yeah,
00:01:03.840 --> 00:01:04.239
sure, yeah, that's totally fine.
00:01:05.660 --> 00:01:06.160
Feel free to just answer them with voice.
00:01:08.720 --> 00:01:09.220
[Speaker 0]: Yeah, yeah. There's another question.
00:01:10.520 --> 00:01:10.920
1 small suggestion to me,
00:01:11.440 --> 00:01:11.940
should means optional,
00:01:13.660 --> 00:01:14.160
where shall or must means required.
00:01:15.940 --> 00:01:16.220
Not sure if it is too late to make a major
00:01:17.220 --> 00:01:17.540
grammar change like that.
00:01:18.080 --> 00:01:18.580
Very nice presentation.
00:01:19.840 --> 00:01:20.340
So thanks for presentation,
00:01:24.380 --> 00:01:24.780
but the package ERT, well,
00:01:27.920 --> 00:01:28.080
it's not something that we have come up with.
00:01:28.920 --> 00:01:29.340
It's a standard package.
00:01:32.320 --> 00:01:32.560
So I believe it has been around for a long
00:01:37.760 --> 00:01:38.000
time. So, but please feel free to make
00:01:39.680 --> 00:01:40.180
suggestions and maybe you can,
00:01:43.660 --> 00:01:43.860
you know, like do a copy or like an alias for
00:01:46.080 --> 00:01:46.200
that. If you believe it makes more sense for
00:01:48.080 --> 00:01:48.580
your test cases to have that instead.
00:01:53.540 --> 00:01:53.720
And then we have another question here.
00:01:55.540 --> 00:01:55.680
For your info, you may find this helpful for
00:01:58.780 --> 00:01:59.020
running MX test lint both from a command line
00:02:01.220 --> 00:02:01.720
and from within MX with a transit menu.
00:02:03.600 --> 00:02:04.040
GitHub alpha papa make sure,
00:02:06.760 --> 00:02:07.100
yes. It also works on remote CI.
00:02:08.240 --> 00:02:08.740
Yeah, thank you, Alpha Papa.
00:02:10.580 --> 00:02:11.080
I think I've looked into that,
00:02:13.440 --> 00:02:13.940
but we haven't made any use of that.
00:02:17.920 --> 00:02:18.080
But maybe you'll inspire me to give it
00:02:18.400 --> 00:02:18.900
another look.
00:02:29.260 --> 00:02:29.760
[Speaker 2]: Hey guys.
00:02:34.120 --> 00:02:34.460
[Speaker 0]: I remember, I recognize that voice.
00:02:37.160 --> 00:02:37.660
Hi, Bob. Hey, how are you?
00:02:40.240 --> 00:02:40.580
Congratulations, man. Thanks,
00:02:43.020 --> 00:02:43.320
Hugh. Thank you. I have another question
00:02:45.520 --> 00:02:45.900
here. It is easy to run ad hoc tests inside
00:02:48.400 --> 00:02:48.600
an Emacs session given the command line
00:02:51.180 --> 00:02:51.560
scripts you need to run to get the batch test
00:02:54.960 --> 00:02:55.120
session running? You said it's to run an
00:03:05.680 --> 00:03:05.920
ad-hoc test. I'm not sure I understand that
00:03:14.440 --> 00:03:14.940
question. Yes, please.
00:03:15.660 --> 00:03:16.160
[Speaker 1]: Maybe I can rephrase. Sure.
00:03:19.900 --> 00:03:20.400
So I think what I understand is that since
00:03:22.540 --> 00:03:23.040
you have to use some of these command lines
00:03:25.440 --> 00:03:25.940
scripts to get a batch test session running,
00:03:28.780 --> 00:03:29.180
is it easy to run ad hoc tests in an Emacs
00:03:30.700 --> 00:03:30.900
session or does that, like in your
00:03:32.040 --> 00:03:32.540
experience, has that been difficult?
00:03:36.820 --> 00:03:37.320
[Speaker 0]: Well, from the command line,
00:03:38.660 --> 00:03:38.940
if you look at the command line,
00:03:44.160 --> 00:03:44.340
you'll see that it's only like a few image
00:03:46.480 --> 00:03:46.980
functions to call to get that behavior to run
00:03:55.080 --> 00:03:55.240
the batch tests. So I think we made some
00:03:57.100 --> 00:03:57.600
support function for that in hyperbole.
00:04:02.800 --> 00:04:02.960
So it's not, I don't think it's possible out
00:04:05.540 --> 00:04:06.040
of the box to do it, but it's not complicated
00:04:08.060 --> 00:04:08.560
to do it.
00:04:12.190 --> 00:04:12.340
[Speaker 2]: You can define a test anytime,
00:04:14.780 --> 00:04:15.280
right? Just like a new function.
00:04:18.899 --> 00:04:19.240
So that's ad hoc. You just write your test
00:04:20.019 --> 00:04:20.519
and you can run it.
00:04:22.900 --> 00:04:23.400
[Speaker 0]: Yeah, yeah, I mean, of course,
00:04:25.900 --> 00:04:26.180
but I got the impression it was about running
00:04:28.620 --> 00:04:29.060
all your tests like we did with the command
00:04:35.740 --> 00:04:36.020
line. Well, so the question is more about how
00:04:38.260 --> 00:04:38.600
would you run all your test cases from within
00:04:44.860 --> 00:04:45.140
Emacs? And the easy answer to that is
00:04:48.420 --> 00:04:48.860
actually you load all your test case files,
00:04:51.760 --> 00:04:52.080
and then you run ERT with the T as the test
00:04:53.600 --> 00:04:53.880
selector and then it will run all your test
00:04:53.880 --> 00:04:54.380
cases.
00:05:01.780 --> 00:05:01.960
[Speaker 1]: Right. And I think they have expanded on
00:05:03.180 --> 00:05:03.520
their question a little bit as well,
00:05:04.960 --> 00:05:05.220
clarifying that. In other words,
00:05:07.200 --> 00:05:07.360
can you tweak tests in an Emacs session and
00:05:08.860 --> 00:05:09.360
run them right away? Which I believe,
00:05:11.400 --> 00:05:11.640
if I understand correctly what Bob was
00:05:13.820 --> 00:05:14.320
saying, you can basically define or redefine
00:05:15.920 --> 00:05:16.080
functions on the fly and then have them be
00:05:16.440 --> 00:05:16.940
run, right?
00:05:22.200 --> 00:05:22.360
[Speaker 0]: Yes, yes. You just go into that test case and
00:05:24.120 --> 00:05:24.620
you just change it and you run it again.
00:05:29.060 --> 00:05:29.200
And either you have to sort of load it or you
00:05:31.560 --> 00:05:32.060
can use like the commercial thing I did.
00:05:36.140 --> 00:05:36.340
You use hyperbole and just hit meta return on
00:05:38.560 --> 00:05:38.860
the test case and it will load it and run the
00:05:42.240 --> 00:05:42.360
test case again. So that's of course what you
00:05:44.220 --> 00:05:44.720
normally do when you're defining a test or
00:05:47.440 --> 00:05:47.940
debug a test case or develop a test case.
00:05:49.960 --> 00:05:50.460
Just start with something small,
00:05:52.700 --> 00:05:53.200
just make sure maybe you can prepare the test
00:05:55.320 --> 00:05:55.680
properly and run it again and again and again
00:05:56.720 --> 00:05:57.220
until you're ready with it.
00:05:59.760 --> 00:05:59.960
That's a good point. You can definitely do
00:06:02.800 --> 00:06:03.280
that and that's part of how I normally
00:06:06.420 --> 00:06:06.920
develop the test cases that I mean start with
00:06:09.160 --> 00:06:09.400
something small so I can see that I get there
00:06:12.180 --> 00:06:12.240
maybe the right input in the buffer that I
00:06:14.180 --> 00:06:14.340
want to test on or something and I expand on
00:06:18.160 --> 00:06:18.400
that more and more and add more and more more
00:06:18.460 --> 00:06:18.960
and more more
00:06:31.040 --> 00:06:31.540
[Speaker 2]: tests to it. You might tell them a bit about
00:06:33.280 --> 00:06:33.480
how many test cases you have.
00:06:36.020 --> 00:06:36.440
I guess you commented on that and like what
00:06:40.320 --> 00:06:40.820
happens, you know, with the CICD pipeline,
00:06:43.780 --> 00:06:44.020
every time we commit, you know,
00:06:46.360 --> 00:06:46.560
across all the versions and what you have set
00:06:48.760 --> 00:06:49.040
up there because you know I wish people could
00:06:53.940 --> 00:06:54.140
see it. You can go and check on GitHub and
00:06:57.440 --> 00:06:57.720
you can see the logs right of any of the
00:06:59.760 --> 00:06:59.960
builds and but tell them a bit about that
00:07:01.080 --> 00:07:01.320
Mats because I think that's pretty
00:07:01.320 --> 00:07:01.820
impressive.
00:07:07.280 --> 00:07:07.760
[Speaker 0]: Well, that's part of more the CI,
00:07:11.760 --> 00:07:12.160
CD, part of how we developed this using
00:07:15.460 --> 00:07:15.580
GitHub and workflows that you get out of the
00:07:20.740 --> 00:07:20.900
box from there. So this more than 300 test
00:07:23.440 --> 00:07:23.720
cases on our round for I think 5 different
00:07:26.480 --> 00:07:26.980
versions of Emacs when we do a pull request
00:07:33.900 --> 00:07:34.400
or a commit. So that's a good way to ensure
00:07:38.040 --> 00:07:38.540
that it works from version 27.2
00:07:42.240 --> 00:07:42.740
up to the latest master version because
00:07:45.860 --> 00:07:46.360
there's some changes in Emacs over different
00:07:48.940 --> 00:07:49.340
versions that can affect your functions or
00:07:49.600 --> 00:07:50.100
your code.
00:07:56.580 --> 00:07:56.720
[Speaker 2]: They all run in parallel and so typically in
00:08:00.580 --> 00:08:00.780
under 60 seconds I think you've got all of
00:08:03.960 --> 00:08:04.460
them run so you've got pretty extensive
00:08:08.860 --> 00:08:09.240
testing which does catch interesting bugs
00:08:09.760 --> 00:08:10.260
here and there, right?
00:08:13.320 --> 00:08:13.820
[Speaker 0]: Yes, of course it does.
00:08:18.060 --> 00:08:18.560
I mean, you normally develop with 1 version
00:08:20.280 --> 00:08:20.540
and then you think everything is okay.
00:08:21.720 --> 00:08:21.820
But then when you're tested with the
00:08:23.460 --> 00:08:23.960
different versions, you find out that there
00:08:26.080 --> 00:08:26.580
are some changes and there are things you
00:08:30.140 --> 00:08:30.400
might not sort of keep track of what's
00:08:34.340 --> 00:08:34.640
happening also. So that's a way to get
00:08:38.559 --> 00:08:38.940
noticed that the core developers of Emacs
00:08:41.120 --> 00:08:41.480
have changed something that you sort of based
00:08:44.380 --> 00:08:44.840
your code on. Now I got another question
00:08:47.900 --> 00:08:48.160
here. Did you have to change hyperbole code
00:08:50.580 --> 00:08:50.760
and design to be more readily testable as you
00:08:52.160 --> 00:08:52.660
were increasing your test coverage?
00:08:55.520 --> 00:08:56.020
Well, we haven't done that to a lot,
00:09:00.160 --> 00:09:00.320
to a big degree, although I believe that that
00:09:03.760 --> 00:09:04.260
is an important thing for sort of the future
00:09:06.020 --> 00:09:06.500
to do that because some of the hyperbolic
00:09:08.520 --> 00:09:08.720
functions are very complicated and long and
00:09:10.640 --> 00:09:11.140
that makes testing them rather difficult.
00:09:14.660 --> 00:09:14.900
So, at a few places we have sort of broken up
00:09:17.260 --> 00:09:17.720
functions in smaller pieces so it'd be easier
00:09:20.280 --> 00:09:20.660
to do like unit tests of the different parts
00:09:27.740 --> 00:09:27.980
of it. But there's a lot of more work that
00:09:28.680 --> 00:09:29.180
has to be done there.
00:09:33.820 --> 00:09:34.020
[Speaker 2]: 1 of the nice things is you know the great
00:09:36.760 --> 00:09:36.820
environment in Lisp where we're able to do a
00:09:40.520 --> 00:09:40.900
lot of interactive bottom-up testing before
00:09:42.840 --> 00:09:43.280
we even get to lighting tech pieces.
00:09:48.740 --> 00:09:49.140
So it does tend to be more higher level bugs,
00:09:51.140 --> 00:09:51.640
I think, that get caught in cross-functional
00:09:55.940 --> 00:09:56.100
interaction. We had 1 recently that was an
00:09:58.100 --> 00:09:58.600
Emacs version change. It had been a function
00:10:01.100 --> 00:10:01.600
that had existed for a long time.
00:10:03.340 --> 00:10:03.840
It had an and rest in it,
00:10:05.740 --> 00:10:06.240
in its argument list, so it would assemble
00:10:08.600 --> 00:10:09.100
the list of arguments from individual
00:10:10.320 --> 00:10:10.820
arguments that you would give it,
00:10:13.100 --> 00:10:13.600
and they decided in a recent version,
00:10:15.200 --> 00:10:15.700
I think with Stefan's input,
00:10:19.400 --> 00:10:19.840
to change that to a list and allow the prior
00:10:22.740 --> 00:10:22.900
behavior, but it would issue a warning if you
00:10:23.620 --> 00:10:24.060
use the prior behavior.
00:10:25.560 --> 00:10:25.840
So all of a sudden, the way you were supposed
00:10:27.180 --> 00:10:27.680
to do it became semi-invalid.
00:10:30.440 --> 00:10:30.940
And so we started getting the warning,
00:10:32.760 --> 00:10:33.040
and we've tried to eliminate all those
00:10:35.600 --> 00:10:36.060
warnings in recent hyperbole developments.
00:10:37.120 --> 00:10:37.620
So we're like, what do we do?
00:10:39.020 --> 00:10:39.440
You know, because we wanted to be backward
00:10:42.140 --> 00:10:42.640
compatible to where you couldn't use a list.
00:10:44.620 --> 00:10:45.120
It required you to use individual arguments.
00:10:48.380 --> 00:10:48.560
And now it's sort of requiring you to do
00:10:51.660 --> 00:10:51.820
that. And all of that was caused by the
00:10:52.940 --> 00:10:53.440
automatic testing on it.
00:11:08.680 --> 00:11:08.860
So you said, Max, you were going to tell us
00:11:12.740 --> 00:11:13.220
what you learned. So what are the major
00:11:15.368 --> 00:11:15.396
things that you learned in doing all of this
00:11:15.680 --> 00:11:16.180
work? All of this work?
00:11:26.520 --> 00:11:26.740
[Speaker 0]: Well, I tried to cover some of it in the
00:11:29.380 --> 00:11:29.800
presentation, but as I was going along,
00:11:33.420 --> 00:11:33.920
the presentation became like twice as long as
00:11:36.180 --> 00:11:36.680
fitted into the time we had so I had to cut
00:11:42.380 --> 00:11:42.880
it out. But I think some of the core things
00:11:44.340 --> 00:11:44.840
still is in the presentation.
00:11:49.560 --> 00:11:50.060
From a personal perspective,
00:11:52.440 --> 00:11:52.940
And this might not be hard to realize,
00:11:56.960 --> 00:11:57.460
but forcing yourself to test functions,
00:12:02.900 --> 00:12:03.060
test code really forces you to understand the
00:12:05.080 --> 00:12:05.280
code a little bit better in a way that sort
00:12:07.300 --> 00:12:07.400
of makes it easier than just to read the
00:12:11.460 --> 00:12:11.960
code. I don't know how it is for the rest
00:12:13.780 --> 00:12:13.980
listening to this, but for me it works so
00:12:16.580 --> 00:12:17.080
that if I just read the code then I don't
00:12:20.140 --> 00:12:20.320
sort of become as sharp as I should be but if
00:12:22.500 --> 00:12:22.640
I try to write the test case for it then I
00:12:24.680 --> 00:12:24.880
really need to understand better of all the
00:12:27.660 --> 00:12:28.160
edge cases and all the sort of states and etc
00:12:30.060 --> 00:12:30.320
that is involved and I think that's That's
00:12:33.080 --> 00:12:33.200
what's sort of 1 of the learning things I
00:12:34.960 --> 00:12:35.280
wanted to communicate as well that I don't
00:12:38.940 --> 00:12:39.080
think I covered in detail in the
00:12:41.480 --> 00:12:41.980
presentation. Maybe all this,
00:12:48.060 --> 00:12:48.340
but try it. 1 other sort of more from the fun
00:12:50.740 --> 00:12:51.000
side is that I really think it's fun to write
00:12:55.080 --> 00:12:55.440
the test. So if you haven't tests in your
00:12:58.020 --> 00:12:58.520
package, you should start doing that because
00:13:05.740 --> 00:13:06.080
it is fun. It might feel like some extra
00:13:08.080 --> 00:13:08.580
work, but it really pays off in the long run,
00:13:10.320 --> 00:13:10.760
especially if you have it in like a pipeline
00:13:12.520 --> 00:13:12.980
and where you can run it regularly when you
00:13:13.940 --> 00:13:14.380
do new commits, et cetera.
00:13:16.560 --> 00:13:17.060
So, I mean, that's maybe obvious from,
00:13:19.160 --> 00:13:19.440
if you look from the commercial side or your
00:13:21.080 --> 00:13:21.340
work side to do it like that.
00:13:22.260 --> 00:13:22.660
But even for your hobby project,
00:13:26.260 --> 00:13:26.760
it can be very sort of pay off really well.
00:13:32.900 --> 00:13:33.160
[Speaker 2]: It's worked really well when we're adding new
00:13:35.020 --> 00:13:35.180
functionality or we're changing some of the
00:13:36.560 --> 00:13:37.060
plumbing in the system.
00:13:40.400 --> 00:13:40.580
You know, you go and you do some surgery and
00:13:41.320 --> 00:13:41.820
then you run the tests.
00:13:45.400 --> 00:13:45.900
And sometimes 6 to 10 tests will fail.
00:13:48.260 --> 00:13:48.420
And you find there, you know,
00:13:50.460 --> 00:13:50.660
it tends to be they're all interconnected and
00:13:52.920 --> 00:13:53.320
it leads you back to the single source.
00:13:56.660 --> 00:13:56.980
You fix that and you know it could be an edge
00:14:00.560 --> 00:14:00.760
case and off by 1 or Sometimes it's an
00:14:03.520 --> 00:14:03.800
assumption about the way something is used
00:14:05.980 --> 00:14:06.480
and it's not actually always true.
00:14:09.520 --> 00:14:10.020
And so, Matt's just really good at
00:14:13.540 --> 00:14:14.040
identifying some of those scenarios and
00:14:17.480 --> 00:14:17.980
keeping us honest, I guess I would say.
00:14:22.900 --> 00:14:23.400
So I love, I run it as much as I before,
00:14:26.400 --> 00:14:26.900
you know, even before I commit something.
00:14:29.960 --> 00:14:30.060
So I get to see, you know,
00:14:30.940 --> 00:14:31.440
if anything has progressed.
00:14:39.480 --> 00:14:39.920
So yeah, I really recommend this process to
00:14:42.120 --> 00:14:42.620
people. I haven't seen it done.
00:14:45.720 --> 00:14:46.080
I don't think that, I don't know any other
00:14:47.800 --> 00:14:48.300
package that has done it to this level.
00:14:51.560 --> 00:14:51.820
And it's been working really great for us.
00:14:55.440 --> 00:14:55.640
And I think, well, we'll see too when we
00:14:56.780 --> 00:14:57.280
release to the general public.
00:15:04.380 --> 00:15:04.540
[Speaker 0]: But Bob, also, maybe the test part of
00:15:06.400 --> 00:15:06.560
different packages is not the first thing you
00:15:08.900 --> 00:15:09.100
look at. So I know there are packages that
00:15:10.960 --> 00:15:11.380
have testing, a lot of testing,
00:15:13.860 --> 00:15:14.160
but how much, much testing they have or not,
00:15:16.060 --> 00:15:16.220
I don't know. It's not what you normally look
00:15:17.900 --> 00:15:18.400
into when you look at someone's else code.
00:15:20.600 --> 00:15:20.820
You look maybe on the functionality side but
00:15:22.760 --> 00:15:23.000
not on how they've done the sort of the
00:15:26.540 --> 00:15:26.760
quality side. So there could be other
00:15:28.780 --> 00:15:29.280
packages out there that are well equipped.
00:15:31.800 --> 00:15:32.300
[Speaker 2]: I hope so. I hope so.
00:15:39.860 --> 00:15:40.180
[Speaker 0]: What's the craziest bug you found when
00:15:44.700 --> 00:15:45.200
writing these tests? Well,
00:15:50.760 --> 00:15:50.940
What springs to my mind just now is that we
00:15:52.760 --> 00:15:52.960
were doing some tests or I would do some
00:15:55.920 --> 00:15:56.420
tests for when you narrow,
00:15:57.940 --> 00:15:58.440
what do you say that? When you,
00:16:04.500 --> 00:16:05.000
in outlining, when you sort of compress
00:16:06.480 --> 00:16:06.980
things in an outline, so you just,
00:16:08.540 --> 00:16:09.040
sorry Bob, maybe you have it,
00:16:12.100 --> 00:16:12.600
[Speaker 2]: When you hide text.
00:16:12.740 --> 00:16:13.240
[Speaker 0]: What I'm looking for? Yeah,
00:16:15.580 --> 00:16:15.920
when you hide. So I was doing some cursor
00:16:17.780 --> 00:16:17.980
movement over that. And I always assume that
00:16:22.540 --> 00:16:22.900
if you do like a prefix argument to like a
00:16:23.800 --> 00:16:24.240
simple cursor movement,
00:16:26.420 --> 00:16:26.920
like control F moving 1 character position,
00:16:28.340 --> 00:16:28.840
and you would give it the,
00:16:36.580 --> 00:16:37.080
and then the prefix, like you want to move
00:16:39.140 --> 00:16:39.640
like 2 or 3 positions,
00:16:43.040 --> 00:16:43.140
you would do like control U 3 and then
00:16:44.240 --> 00:16:44.740
control F and you move 3.
00:16:46.560 --> 00:16:46.960
I always assumed that that would be exactly
00:16:49.240 --> 00:16:49.440
the same as if you just hit the key control F
00:16:50.740 --> 00:16:51.240
3 times, but it's not.
00:16:53.160 --> 00:16:53.560
So it's not the bug, it's a feature,
00:16:54.620 --> 00:16:55.080
but that was the craziest thing.
00:16:58.180 --> 00:16:58.360
I spent the night trying to figure out why
00:17:00.720 --> 00:17:01.000
our code was wrong, but It turns out that's
00:17:03.560 --> 00:17:04.060
how Emacs behaves. Try it out yourself.
00:17:07.920 --> 00:17:08.300
Try to move over the 3 dots at the end of
00:17:09.140 --> 00:17:09.640
that and see what happens.
00:17:14.060 --> 00:17:14.240
Do it with cursor hitting the key or using a
00:17:16.260 --> 00:17:16.680
prefix argument and you see it behaves
00:17:18.720 --> 00:17:19.220
differently. That was the craziest thing.
00:17:21.960 --> 00:17:22.339
I think there was some other crazy thing or
00:17:24.280 --> 00:17:24.480
deep learning also, but I can't come up with
00:17:26.599 --> 00:17:26.760
it at the moment. So maybe I can write it in
00:17:27.900 --> 00:17:28.400
the Q&A later.
00:17:31.200 --> 00:17:31.440
[Speaker 1]: I think we're out of time on the stream,
00:17:33.360 --> 00:17:33.600
but people are welcome to join Mats and Bob
00:17:35.280 --> 00:17:35.640
here on BigBlueButton to further discuss
00:17:36.480 --> 00:17:36.980
this. Thank you both.
00:17:38.674 --> 00:17:38.792
[Speaker 0]: Okay, thank you. Thanks,
00:17:46.100 --> 00:17:46.600
Makaay. Thank you. I don't know,
00:17:48.740 --> 00:17:49.240
Is it only me and Bob here?
00:17:50.680 --> 00:17:51.180
So Bob, do you want to say something?
00:17:57.440 --> 00:17:57.940
[Speaker 2]: Well, I think it's been a great day.
00:18:00.720 --> 00:18:01.220
And I'm glad we did this.
00:18:02.280 --> 00:18:02.780
It takes a lot of energy.
00:18:15.140 --> 00:18:15.640
I'm just really excited about the progress
00:18:20.580 --> 00:18:20.740
that this, and we're actually doing a lot of
00:18:23.940 --> 00:18:24.160
QA at work and my professional software work
00:18:28.500 --> 00:18:28.840
and looking at you know how we can do more
00:18:32.980 --> 00:18:33.480
test driven development and so everybody's
00:18:35.980 --> 00:18:36.200
talking about this you know we've got AI over
00:18:37.540 --> 00:18:38.040
here that can generate test cases.
00:18:40.200 --> 00:18:40.700
But, you know, strangely enough,
00:18:43.100 --> 00:18:43.380
with the rapidity of development and web
00:18:46.720 --> 00:18:47.220
applications, I think the level of testing
00:18:50.140 --> 00:18:50.280
has gone down in recent years compared to
00:18:51.500 --> 00:18:51.780
where it used to be, right?
00:18:53.040 --> 00:18:53.540
Because the pace has gone up.
00:18:57.340 --> 00:18:57.840
And so I think it's starting to turn again
00:18:58.740 --> 00:18:59.240
where people are saying,
00:19:01.940 --> 00:19:02.440
we can't just release crap into the
00:19:08.120 --> 00:19:08.620
Webisphere and we have to better ourselves.
00:19:13.620 --> 00:19:13.820
And with all these advanced tool sets that
00:19:16.100 --> 00:19:16.600
you have, that you can do CICD testing,
00:19:19.860 --> 00:19:20.180
you know, I just, I just see it coming
00:19:21.900 --> 00:19:22.100
around, you know, as people develop new
00:19:24.000 --> 00:19:24.160
things. So That's kind of exciting to me
00:19:26.980 --> 00:19:27.480
because I came from a manufacturing culture
00:19:30.300 --> 00:19:30.780
originally where we, our company actually
00:19:33.800 --> 00:19:34.300
started a lot of the manufacturing quality
00:19:37.420 --> 00:19:37.920
efforts that you saw in Japan and elsewhere
00:19:40.600 --> 00:19:40.740
in America for a long time and that was you
00:19:42.040 --> 00:19:42.540
know entirely through testing.
00:19:46.640 --> 00:19:47.020
We used to just build incredible test cases
00:19:49.120 --> 00:19:49.320
because we were combining software with
00:19:51.100 --> 00:19:51.380
hardware. And if, you know,
00:19:53.460 --> 00:19:53.600
the hardware doesn't work and you ship a
00:19:55.080 --> 00:19:55.520
million units, you're,
00:19:57.340 --> 00:19:57.840
you're in trouble. So,
00:20:00.260 --> 00:20:00.760
that was just something we had to do.
00:20:04.280 --> 00:20:04.780
And so it's nice to start to see that curve
00:20:07.020 --> 00:20:07.520
come around. And I think,
00:20:10.380 --> 00:20:10.880
you know, Matt Vance is very modest,
00:20:16.680 --> 00:20:16.920
but I think he's really the 1 that started us
00:20:20.400 --> 00:20:20.580
down this path and really made it into a
00:20:24.620 --> 00:20:24.840
reality. So everybody else just gets to
00:20:25.760 --> 00:20:26.260
benefit from that work.
00:20:27.540 --> 00:20:28.040
So thanks.
00:20:32.760 --> 00:20:33.260
[Speaker 1]: That's awesome.
00:20:39.960 --> 00:20:40.460
[Speaker 0]: Thanks. Okay. Yeah. So if there's nothing
00:20:43.200 --> 00:20:43.520
more here, then maybe we should just close
00:20:45.440 --> 00:20:45.940
this and I go over to write in the etherpad
00:20:47.960 --> 00:20:48.460
the replies we had.
00:20:51.900 --> 00:20:52.120
[Speaker 1]: Right, yeah, I think, let's see,
00:20:53.520 --> 00:20:53.760
I see 1 other person here,
00:20:55.080 --> 00:20:55.580
I believe Ihor just joined us.
00:20:58.780 --> 00:20:59.060
Yeah. Yeah, so if you do want to discuss with
00:21:00.220 --> 00:21:00.480
Mats and Bob, you're welcome to,
00:21:02.200 --> 00:21:02.700
otherwise, yeah, we can close the room now.
00:21:05.800 --> 00:21:06.020
[Speaker 3]: Well, I think I missed most of the talk
00:21:06.900 --> 00:21:07.400
because I had power outage,
00:21:12.180 --> 00:21:12.440
but the part I heard was about the mock
00:21:16.860 --> 00:21:17.220
library. And you mentioned that you don't
00:21:20.200 --> 00:21:20.700
like CL-let, but instead you use mock.
00:21:29.700 --> 00:21:29.800
[Speaker 0]: Yeah, I was more saying that you have to do a
00:21:31.560 --> 00:21:32.040
lot more work when you use the CL letdef.
00:21:34.540 --> 00:21:34.780
It's for more ambitious and maybe more
00:21:37.000 --> 00:21:37.500
complicated cases where you want to really
00:21:38.840 --> 00:21:39.340
make a new implementation,
00:21:41.940 --> 00:21:42.440
test implementation. If you use the mock,
00:21:44.380 --> 00:21:44.880
you get a lot of things out of the box,
00:21:47.440 --> 00:21:47.940
verifying that you actually,
00:21:50.820 --> 00:21:51.040
like the mock was actually called for
00:21:53.320 --> 00:21:53.820
instance, whereas if you do with the CLLatf,
00:21:56.520 --> 00:21:56.780
you would have to take correct track of that
00:22:02.020 --> 00:22:02.520
yourself. And so, so a lot of more work.
00:22:03.760 --> 00:22:04.260
Oh yeah.
00:22:07.940 --> 00:22:08.200
[Speaker 3]: I'm saying that most of the time CLLess is
00:22:09.720 --> 00:22:10.220
used for simple cases actually.
00:22:12.320 --> 00:22:12.820
Because, just for example,
00:22:15.100 --> 00:22:15.600
the function always returns the same.
00:22:17.980 --> 00:22:18.420
And it tends to be simple lambda that ignores
00:22:19.040 --> 00:22:19.540
all the input arguments.
00:22:23.000 --> 00:22:23.480
So that's really trivial most of the time but
00:22:25.520 --> 00:22:25.920
I actually thought the opposite that mock is
00:22:27.640 --> 00:22:28.140
supposed to be used for non-trivial cases.
00:22:32.280 --> 00:22:32.520
[Speaker 0]: Sorry, what was the question?
00:22:35.280 --> 00:22:35.780
Mock was supposed to be used for non-trivial.
00:22:47.680 --> 00:22:48.180
Yeah I mean I don't know how to explain this.
00:22:50.140 --> 00:22:50.640
I mean, CLF can be used for non-trivial
00:22:54.400 --> 00:22:54.840
definitely. You can define then any behavior
00:22:56.180 --> 00:22:56.680
you want. You can write your own function,
00:22:58.440 --> 00:22:58.660
but you need to keep track of whether that
00:22:59.620 --> 00:23:00.100
function is called or not,
00:23:06.260 --> 00:23:06.380
for instance. So you have to make note of
00:23:08.440 --> 00:23:08.940
that the function was called so you can fire
00:23:12.440 --> 00:23:12.800
sort of an error in case your function wasn't
00:23:16.960 --> 00:23:17.440
called because that would be 1 error case.
00:23:20.660 --> 00:23:20.860
[Speaker 3]: So you mean the mock fires an error if the
00:23:22.580 --> 00:23:23.080
mocked function was actually not called?
00:23:30.060 --> 00:23:30.560
[Speaker 0]: Yes, it does. Yes. So if your assumptions,
00:23:33.900 --> 00:23:34.120
you sort of document with the mock also your
00:23:37.080 --> 00:23:37.220
assumptions how your code is going to be
00:23:40.020 --> 00:23:40.380
called. And if those are wrong,
00:23:41.120 --> 00:23:41.540
you will get an error.
00:23:43.680 --> 00:23:44.060
So you would, so if the implementation would
00:23:44.840 --> 00:23:45.100
maybe change, for instance,
00:23:46.640 --> 00:23:47.140
and not call the thing you're mocking,
00:23:50.460 --> 00:23:50.960
then you will notice that.
00:23:53.100 --> 00:23:53.560
But if you see a letdef,
00:23:54.840 --> 00:23:55.040
then you will have to keep track of that
00:23:57.560 --> 00:23:58.060
yourself. Okay, I see.
00:23:58.260 --> 00:23:58.760
I see.
00:24:01.240 --> 00:24:01.740
[Speaker 3]: And you know, our mode also uses a lot of
00:24:09.340 --> 00:24:09.620
test. In our mode, we have a lot of tests
00:24:13.940 --> 00:24:14.440
[Speaker 0]: Ah, okay. Yeah. Yeah. I'm sure I have.
00:24:15.900 --> 00:24:16.400
[Speaker 3]: also. We rely on CLLatF for,
00:24:19.220 --> 00:24:19.720
we don't use third-party libraries at all.
00:24:22.140 --> 00:24:22.640
[Speaker 0]: Oh, you use CLLatF, okay.
00:24:26.680 --> 00:24:27.180
Yeah. Yeah. Yeah. At First I found it very
00:24:29.480 --> 00:24:29.700
powerful to use that, but then I sort of,
00:24:32.120 --> 00:24:32.320
I learned more about how we can use the
00:24:34.340 --> 00:24:34.840
mocking library for what I needed.
00:24:36.900 --> 00:24:37.400
And I prefer that at the moment.
00:24:40.560 --> 00:24:41.060
[Speaker 3]: I see, that is interesting.
00:24:42.500 --> 00:24:42.700
Because I had seen it,
00:24:45.440 --> 00:24:45.600
but I didn't consider that it's gonna be
00:24:46.800 --> 00:24:47.300
useful even in simple cases.
00:24:52.640 --> 00:24:53.140
[Speaker 0]: It has its limitations.
00:24:58.260 --> 00:24:58.760
So it's like life, how you turn depends.
00:25:03.740 --> 00:25:04.020
But maybe I should look more into the org
00:25:05.880 --> 00:25:06.100
mode and the test case to learn more about
00:25:07.480 --> 00:25:07.980
that. So thanks for pointing that out.
00:25:14.620 --> 00:25:15.120
[Speaker 3]: We are trying to cover as much as we can.
00:25:17.520 --> 00:25:17.740
It's almost impossible for org.
00:25:20.500 --> 00:25:21.000
But yeah, we keep adding more tests.
00:25:22.780 --> 00:25:23.280
[Speaker 0]: That's great.
00:25:52.720 --> 00:25:53.200
Someone's typing. I don't know.
00:25:54.340 --> 00:25:54.840
Any more questions? No?
00:26:01.060 --> 00:26:01.560
Okay, then I'll go back and try to document
00:26:05.200 --> 00:26:05.360
this in the etherpad. Thank you everybody for
00:26:08.860 --> 00:26:09.160
[Speaker 1]: Thank you guys. Great work.
00:26:09.400 --> 00:26:09.900
[Speaker 0]: joining. Great. Thank you.
00:26:11.100 --> 00:26:11.600
Take care. Bye-bye.
00:26:15.060 --> 00:26:15.560
[Speaker 1]: Take care. Bye. Silence.
