00:00:24.660
all right let's talk some mini tests I want to start off with a pole if you
00:00:32.349
guys were to start a brand new project today that you had one hundred percent control over what test framework would
00:00:40.300
you choose raise your hand if you'd use test unit not that many how about our
00:00:48.489
spec a lot more about something else
00:00:53.850
what would you use many tests oh geez mate does anything other than mini test
00:01:00.729
test unit or r-spec nothing
00:01:08.090
okay so today I want to talk about many
00:01:13.310
tests i've been using test unit for several years about a year and a half ago i started using our spec i really
00:01:20.119
liked it but then a few months ago i started using many tests and today i
00:01:25.880
want to share with you my experience with it and how its simplicity one be over my name is jared knee you can find
00:01:38.869
me at red ninja calm thanks mom and dad
00:01:47.920
so when i was putting together this talk i googled for simplicity quotes and this
00:01:54.349
one really kind of jumped out at me Frank Lloyd Wright said this the architect should strive continually to
00:02:00.799
simplify the ensemble of the rooms should then be carefully considered that comfort it utility may go hand-in-hand
00:02:06.890
with beauty and the reason why this really jumped out at me was because it sounded almost like he was talking about
00:02:12.889
programming so I did a little bit of substitution the programmer should
00:02:21.859
strive continually to simplify code should then be carefully considered that intuition and functionality may go
00:02:29.209
hand-in-hand with beauty so functionality does your code do what you
00:02:35.720
thought it was supposed to do and intuition when you look at your code doesn't make sense to you right away so
00:02:46.220
this is the big one the ability to simplify means to eliminate the
00:02:51.319
unnecessary so that the necessary may speak
00:02:58.810
commits like this one from john leighton make me happy Aaron Patterson is
00:03:04.599
referring to this commit he did a refactor Aaron Patterson did a refactor and John Layton took that refactor and
00:03:12.690
deleted 72 lines of code and replaced it with six lines of code and it did exactly the same thing so I think most
00:03:25.300
people can agree that simple code is better it's faster it's more readable
00:03:32.410
and it's easier to understand and we've been told many ways of how to achieve
00:03:39.280
this shorter methods don't be too clever don't put too much magic in your code
00:03:48.569
Occam's razor wikipedia defines it as the principal urging want to select
00:03:54.400
among competing hypotheses that which makes the fewest assumptions and thereby offers the simplest explanation of the
00:04:00.400
effect I don't know about you but I prefer Jodie Foster's definition in
00:04:06.579
contact all things being equal the simplest answer is usually the right one
00:04:17.000
so how can we apply Occam's razor to code well I think it applies with the
00:04:23.360
red green refactor cycle so red being you write a test that fails you
00:04:29.480
implement it make the test go green and then you go back and refactor it and you go through the cycle over and over again
00:04:35.300
until what you end up with is something that you're happy with so anybody that's actually gone through this cycle usually
00:04:42.890
finds out that when you refactor your code ends up being having shorter
00:04:48.200
methods it's not too clever has less magic it's better faster more readable easier to understand so this is us
00:04:55.490
continually striving for simplicity but
00:05:03.470
does this apply to all code like what about code that you don't write like the
00:05:11.570
tools like gems does this apply to your test framework I definitely think it
00:05:18.230
does
00:05:23.760
so Ruby unit testing we basically have two very popular choices test unit it's
00:05:33.160
been around forever we all know it and our spec and no i'm not saying our spec
00:05:39.610
is evil it just happens to fit my analogy so there's a debate on which
00:05:47.770
one's better why do we need our spec at all but today i think we should start
00:05:53.920
talking about another test framework and that is many tests
00:06:06.610
so what makes many tests awesome well it's small it's fast there is a little
00:06:15.610
bit of magic but one of the things I want to do today is to show you what's going on behind the curtains so it
00:06:21.280
doesn't seem as magical anymore the biggest thing it has going for it is that it's really simple and you already
00:06:32.710
know how to use it let me explain what I mean by that mini test is basically a
00:06:43.229
drop-in replacement for test unit so this should look awfully familiar to
00:06:48.370
anybody that's ever used test unit alright we still have a class to subclass of something you define your
00:06:54.699
test by starting with the word test and underscore still using assertions this
00:07:00.189
should look really really familiar so the only real difference is that it's a
00:07:06.279
subclass of something that you're not used to that's not a big deal most of the assertions that you're used to using
00:07:12.729
are still there they did remove a few of them but ever since I've been using it I
00:07:17.949
haven't noticed so they've removed some of the lesser-known lesser-used assertions mini test is also an r-spec
00:07:29.050
alternative and for me to switch from
00:07:34.360
r-spec too many tests it's got to have the readability still right that's that's what we all love about our spec
00:07:40.089
right but we already have test unit and test unit is really solid so if we could
00:07:48.099
possibly use test unit to get an r-spec
00:07:53.319
i'll turn to them out of it without reinventing the wheel that would be awesome oh sorry so I like the
00:08:00.400
readability of our spec for the same reason why I like 2+2 syntax / parentheses plus 22 syntax mmm
00:08:11.270
so here's the challenge we need to get specs style to use test unit which is
00:08:18.720
the assertion right so can we get the code on the left to eventually call the
00:08:25.349
code on the right for your r-spec users this may not look familiar you probably used to mattress but a long time ago
00:08:33.390
r-spec was actually written this way I think it was like version point three or
00:08:38.430
something like that but the important thing here is the readability that syntax the order so let's do a little
00:08:46.440
bit of pseudo TDD our goal is to get the
00:08:53.010
code on the top to call the code on the bottom let me show you how really easy this is so the first thing we need to do
00:08:59.820
is be able to call should equal on any object so that's really easy right you
00:09:07.920
just open up the object class and define your method next thing we need to be
00:09:14.700
able to give it an argument also very easy now we actually already have
00:09:21.360
everything we need to call this assertion right
00:09:28.180
and because we're already inside the object we can refer to the actual value as self and if we just make one small
00:09:38.350
modification we change should too must
00:09:46.140
that is basically mini test spec so I've just shown you how easy it is to get
00:09:53.700
specked style readability using plain Ruby without inventing a whole new test
00:09:58.870
framework so here's what a spec style
00:10:06.310
mini test suite would look like this is a complete runnable sweet so this should
00:10:11.680
also look pretty familiar to our spec users to write so we saw our described blog or it block and then inside it
00:10:17.770
we're using what many test calls expectations so let me show you what's
00:10:25.510
what mini test is doing behind the scenes with your describe block it's basically just making a class out of it
00:10:32.770
and making it a subclass of mini test spec and many tests spec is just a
00:10:38.380
subclass of mini test unit test case which is what we use before with the test unit style the it block basically
00:10:47.680
what it's doing in the background is just defining a method that starts with tests underscore it is doing a little
00:10:54.490
bit more but the important part is it's just defining a simple method that
00:10:59.500
starts with test underscore
00:11:06.760
so when you get the mini test library there's a file in there called history txt it's essentially just their change
00:11:13.750
log and I started reading through this and I'm going to share with you a couple of lines that caught my eye remove this
00:11:21.730
unnecessary remove that unnecessary removed pretty print tests run 2 times
00:11:27.010
faster but this one is the most important one removed as much code as I
00:11:34.360
could while still maintaining full functionality that is a really good practice if you want simple code
00:11:47.220
so let's do another poll except this time let's start with everybody's hands up if you have already used mini tests
00:11:57.810
put your hand out just
00:12:03.870
if you are still using ruby 1.8 you have not yet upgraded to Ruby 19 put your
00:12:09.960
hand down that's way too many hands okay
00:12:16.560
if your hand is still up I'm going to make an assumption about you put your hands down now either you're using Ruby
00:12:26.010
19 and you've at least use the test unit at some point in time in Ruby 19 or
00:12:35.270
you're not testing at all and if you're not testing at all excuse me while I go
00:12:41.100
on a little tangent here like I'm going to tell you the story of me before and after I started using testing it
00:12:49.410
actually took me quite a while to buy into testing to adopt testing I didn't really see the point of it I figured if
00:12:56.460
you have a bug fix it into story what's the big deal but as you probably know
00:13:02.220
some bugs are harder to squash than other bugs but I'd attempt to squash
00:13:09.690
these bugs too but sometimes more often than I would care more often than I like
00:13:17.510
these bugs come back and whip your butt right and for anybody that's been down
00:13:24.930
in the trenches fighting these bugs do you know that your life is miserable when you're doing this not to mention
00:13:31.860
you make your co-workers miserable too because when you're not testing you're
00:13:37.650
breaking their code they're breaking your code you're cleaning up their mess they're cleaning up your mess it's just really not fun so I started practicing
00:13:46.860
testing I got better at it especially using TDD and I finally woke up one day
00:13:53.490
and realize testing is really useful how did I not do this before I can't live
00:13:58.529
without testing anymore and I have to tell you that was probably one of the biggest most important basic level up so
00:14:05.940
I've ever had as a ruby developer so now I still have bugs just like
00:14:11.910
everybody else but these bugs are a little bit smaller a little bit more easier to manage so occasionally I users
00:14:20.250
are minorly inconvenienced by bugs but now this is what it feels like to squash bugs because I know how to test okay so
00:14:33.779
back to this if you're using Ruby 19 and test unit guess what you're already
00:14:40.020
using mini test because in Ruby 19 test unit is built right on top of many tests
00:14:49.459
which also means you get many tests for free when you test this package with Ruby 19 it does come in a standalone gem
00:15:00.649
Ruby 19 does keep up with all the updates with the gym but if you don't
00:15:05.700
feel like installing a whole bunch of different Ruby patch levels just install the gym you can always get the latest
00:15:11.550
one whenever you want so how hard is it
00:15:19.709
to switch the mini test if you're coming from test unit you won't have a problem
00:15:25.589
because like I said it's pretty much a drop-in replacement if you're coming
00:15:32.010
from r-spec it'll still feel mostly familiar it might feel like it's missing
00:15:39.120
some features but I promise you it doesn't take that long to get used to it and you'll find out that some of the
00:15:46.560
things that you're missing can actually be accomplished with really simple Ruby
00:15:52.220
there is a lot of our spec stuff built in you still have before blocks after blocks let subject specify there's
00:16:00.060
probably more and judging by the comments in the source code they included these things for the sole
00:16:06.060
purpose of making our spec users happy
00:16:12.380
the first thing that I missed when I switch from our spec too many tests was the ability to define custom matchers so
00:16:20.850
for example if I wanted to test that 42 should be a multiple of three this is
00:16:26.399
what I would do in r-spec so you define a mature you give it the name define
00:16:34.110
your match block and you defined your failure message so many tests doesn't
00:16:43.020
have custom matches and because when you want spec style expectations and because
00:16:50.670
it uses test unit style we have to define the assertion first so let's do that so we need to define a cert
00:17:01.020
multiple of the multiple in the number if you just open up the mini test
00:17:06.990
assertions module anything you define in there automatically gets included in your test so we're defining the
00:17:16.050
assertion giving it the arguments building the failure message and call a
00:17:23.880
new Saoirse so anybody that's ever done a custom is our custom assertion this should look familiar
00:17:34.100
so how do we get the assertion to be called by the spec style expectation so
00:17:43.160
I copied this from the earlier slide where I showed you how easy it is to to get spec style to call the assertion so
00:17:50.960
what's the what's the only difference here well the name of the expectation
00:17:57.370
and the name of the assertion that's it
00:18:04.390
but you don't want to do this over and over again and need it as many tests so they introduced this method to dry
00:18:10.909
things up it's called infect an assertion and it does all of that for
00:18:16.340
you all you have to do is just give it the name of the assertion that you
00:18:21.409
defined give it the name of the expectation that you want it that you
00:18:26.929
want and it'll do all that for you one little wrinkle instead of the object
00:18:34.220
class I'm going to switch that out with the numeric class so that now only
00:18:39.850
numeric objects are able to call must be multiple of
00:18:49.799
so many test uses this for all its expectations if you go in the source
00:18:55.110
code and look at the expectations module there's there's no method definitions all it is is a whole bunch of infective
00:19:02.309
assertions so what's this last argument
00:19:08.489
this is an optional argument the
00:19:14.639
convention is when you define an assertion is you give it the expected value first and then the actual value
00:19:21.149
last but it's just the opposite with spec style right there flipped so many
00:19:33.119
tests knows this and it assumes when you define a custom expectation that you naturally want to flip these so when you
00:19:42.389
call infective assertion this is what it's doing behind the scenes it's flipping them for you but what about
00:19:50.039
other expectations like this must be empty where there is no argument to flip
00:19:57.200
well if we went ahead I'm sorry this is what the assertion should look like if
00:20:04.320
we call infect an assertion just like we did before it's going to try to flip
00:20:10.529
those arguments for us and it uses arguments flats and so when you take the
00:20:16.769
first argument of an empty array you get nailed right so it's trying to shove an
00:20:22.379
ill into that assertion when we don't want it to which is why we need this last argument we're telling mini test
00:20:28.350
don't worry about flipping I'll take care of it
00:20:38.630
let me show you how I use infective assertion to write a gem I use capybara
00:20:44.360
a lot this is what a typical capybara test might look like in r-spec so you
00:20:50.360
have page should have content right but I would like to be able to convert this
00:20:56.960
to mini test specs style where we can say page must have content so all I did
00:21:04.490
was define the assertion the cert page has content I called in fact an
00:21:09.860
assertion on it and I did this for every built-in node mature in capybara and
00:21:17.270
that's all I did and to test this I literally took the spec file inside
00:21:22.850
capybara that tests the mattress and I took everywhere that it said should
00:21:28.850
something I literally just replaced it with must whatever the expectation is
00:21:34.610
and there was a little bit of small tweaking that I had to do but I love that that's all I did so here's another
00:21:44.690
thing that i missed when i switch from our spec too many tests shared behaviors test examples whatever you want to call
00:21:50.240
it so here's a very small piece of code we have a mic buyers module and i have
00:21:59.900
two classes dr. evil in austin powers and i'm simply including that module in each one of those so now that now dr.
00:22:06.650
evil and austin powers has mike myers abilities included in there this is what
00:22:14.090
I would have done in r-spec if I wanted to test to make sure that dr. evil and Austin Powers is including Mike Myers so
00:22:21.770
you define the shared example by name and then whatever comes inside there is just a regular test right and now that
00:22:28.760
test is shareable among other tests and the way you bring those tests in is you
00:22:36.170
just call include examples and you give it the name well when a test doesn't
00:22:41.270
have shared behaviors so I had to do it myself and that really doesn't sound as
00:22:46.910
hard as as it is but I really wanted to do was just simply include a module because
00:22:52.830
that's really all it's doing right when you include a module you get those methods include it that's all tests are
00:22:58.799
just methods so this is how i implemented it
00:23:09.330
to find the module call self included on it and did some class eval to find the
00:23:15.780
test this might look a little bit ugly to you but if you understand how modules
00:23:23.910
work and you're used to working with modules this should be a walk in the park for you
00:23:34.010
mmm however before you start thinking about how to define shared behaviors
00:23:39.620
examples tests the first thing you should think about is whether or not you should extract it into a gym because
00:23:45.560
gems are a lot easier to test because they're isolated and it also removes those tests from your application into
00:23:52.640
the gym so it cleans up your app tests as well so think about whether or not you should extract it into a gym first
00:24:01.840
so let's say you do switch the mini tests and you feel kind of lost there's
00:24:07.070
actually a whole bunch of extensions that people have written so if you feel
00:24:12.950
like you're missing some features go check out the extensions and see if somebody has already filled in the gaps for you so now that you got the basics
00:24:23.000
down let's talk about another library in mini test the mocking library
00:24:32.070
there's a simple piece of code a simple class called mockingbird and when I
00:24:37.650
create a new Mockingbird I'm going to give it a twitter client when I tell that Mockingbird is saying you should
00:24:43.710
tweet something and return the status
00:24:52.310
so here's what the test would look like I don't want to bother with twitter I
00:24:57.620
want to be able to run my tests even if I don't have internet so I'm going to pretend that I have a twitter client i'm
00:25:02.900
going to mock it and you do that by calling mini test mock new and with that
00:25:09.830
mocks twitter client you can tell it to expect a tweet method and when it gets
00:25:16.220
that tweet method called on it it should return two hundred and that last part is
00:25:21.310
the arguments that you expect and notice that i'm just giving it the string class not a specific string even though you
00:25:27.230
can do a specific string and now i'm
00:25:33.020
creating a new mocking bird just like normal but instead I'm giving it this fake Twitter client now when i call bird
00:25:42.170
sing it should do all that tweeting for me and this is how I verify that it's
00:25:50.720
being called so for some reason tweet was not called on that mocked object this test would fail this is a really
00:25:58.850
cool library it's actually very tiny it's a little bit more than 100 lines of code so obviously when you talk about
00:26:06.950
mocking you got to talking about stuffing right well mini test does not have a stubbing library and let me tell
00:26:14.750
you this really threw me off because I didn't understand why you would have mocking but not stubbing because they
00:26:20.570
seem to go hand in hand right
00:26:26.330
so this really threw me off until I watched Ryan Davis's talk ryan davis is
00:26:31.410
one of the authors this was at cascadia Ruby I think last year and in that talk
00:26:38.040
he explained why there is no stub library and he quoted Phil hackleburg who said death is my stub framework let
00:26:46.140
me show you what he means another simple kept simple class to stubbing bird and I
00:26:53.640
compare it to something it'll ask have you heard and if you have her it'll just return true and in there if you haven't
00:27:00.480
heard it's going to play a really annoying song so here's what the test
00:27:08.520
looks like I'm creating a new stubbing bird just
00:27:13.870
like normal but here's the trick I'm defining a singleton method on that bird
00:27:20.430
so now this bird only this bird in this test has the method have you heard to
00:27:26.860
find on it not any other bird just this bird that we're talking about in this test and when it does get called when
00:27:33.520
have you heard gets called on it I'm forcing it to return true that's what he
00:27:39.520
meant by deaf is my stubbing library framework so now when I compare the bird
00:27:45.820
to the word I should get true
00:27:53.880
however I should warn you that mocking and stubbing should be done very sparingly Ryan Davis likes to call it
00:28:01.560
over mocking I like to call it Frank and stubby and the reason is because when
00:28:08.190
you over Mach and you over stub you're making a whole lot of assumptions your mate you're you're gathering a whole
00:28:13.260
bunch of fake stuff let me put it this way which tests would you trust more a
00:28:18.570
test that runs close to the real world or a test that has a whole bunch of fake
00:28:23.880
stuff in it so that means you should probably only be stubbing and mocking
00:28:30.030
maybe like third party stuff like Twitter external clients that you have
00:28:36.660
no control over those are the things that I think are probably okay to stub and mom but other than that if you can
00:28:43.020
test without stubbing and mocking you should definitely do it that way in fact Ryan says you always should make your
00:28:50.490
test pass before you even stub and mock stuff here's a feature that I like in
00:29:00.060
many tests you can customize your air output so pretend we have two articles
00:29:07.020
here and when I compare the two they are not the same this is what you get by
00:29:12.660
default so many tests will take each one of those objects that you're trying to
00:29:17.820
compare and call inspect on it and whatever the result of that inspect is
00:29:24.210
it will put in a temporary file and it does this for each of the objects and it does a diff on those two object or two
00:29:31.290
files temp files but you can see that
00:29:37.280
this can be a little bit difficult to tell where the actual discrepancy is especially when you imagine like an
00:29:43.320
active record model that has you know 10 15 different attributes on it if it's all blurted out all on one line it's
00:29:49.320
really difficult to see where the difference is so I want it to be able to
00:29:54.840
use awesome print awesome print is a gym that makes output a little bit prettier
00:30:00.330
it does color coding it does multi-line output
00:30:05.760
so the advantage here is that if we can diff two awesome print outputs it's a
00:30:12.010
lot easier to tell where the difference is and it turns out this is actually really easy to do all you have to do is
00:30:19.420
override mini test assertions method called mu underscore PP I believe that
00:30:25.120
stands for mini test unit pretty print but i'm not i'm not quite sure
00:30:34.400
here's another output feature that i really like mini test pride in the
00:30:40.340
command line when you run your tests by default this is what your output looks like but if you include require mini
00:30:49.070
test pride this is what you're out that looks like it does nothing but colorize your dots this is what failures and
00:30:58.490
errors look like
00:31:09.740
reading the source of mini test it was a lot easier to read than a lot of other
00:31:15.629
libraries that I've read I'm just real quick though another quick level up tip
00:31:20.840
read your source code this is very important Google and stack overflow all
00:31:27.000
we know so much okay if you're asking about code that you're using it's right under your nose so open it up and read
00:31:33.179
it as a practice go somewhere that doesn't have internet and work for a
00:31:38.610
couple hours and as soon as you run into a problem that you can probably find the answer in your code this will force you
00:31:44.549
to dive into your source code and find the answer yourself if you're using
00:31:49.679
Butler on the command line you can call bundle open in the name of a gem and
00:31:55.250
bundler will open up an exact version that your application is using and whatever editor you want so you don't
00:32:01.710
even have to know where its installed and when you do this you start getting you start practicing this you start
00:32:08.070
reading code and you start finding functions that you never knew existed so I found one in many tests that I thought
00:32:14.460
was kind of funny by default your tests and mini tests are run in random order every single time you run a test and the
00:32:21.899
reason why they do this is to make sure to try to separate all your tests out and make sure that there are any weird
00:32:27.779
order dependencies on the order that your tests to run and for whatever reason you want to turn this feature off
00:32:33.450
again but you have to call I suck and my tests are order dependent back
00:32:47.500
so many test is just about six files this is their lines of code you can see
00:32:54.130
that a lot of the files are actually pretty small and even still a big chunk
00:32:59.680
of that code this documentation so that makes mini tests really easy to read
00:33:06.510
which is really important because the easier it is to read the better chance you have with understanding what's going
00:33:11.890
on and that's important because the more you understand the more control you have over it so how fast is mini test well
00:33:24.970
honestly I don't care that much if you really want to know go watch Ryan
00:33:30.490
Davis's talk he has some really nice graphs he compares the lines of code in
00:33:36.070
mini tests to other libraries like r-spec cucumber and some other ones I've
00:33:41.320
never even heard of he even compares not only the lines of code written but lines
00:33:46.660
of code executed when you run your tests which is really interesting but really I
00:33:53.410
believe that 99% of your test speed is in your code not the test frameworks
00:33:59.740
code so yes mini test is fast but that's really just a side effect of its
00:34:05.790
foundation of simplicity in its design
00:34:12.250
so the simplicity of mini tests ends up being the main benefit it's the whole driving force behind how it was written
00:34:19.030
just about everything that's good about it comes from the fact that it is simple
00:34:25.330
and I really like that because it ends up influencing my code quite a bit my
00:34:37.540
test got better too because now when I test I keep asking myself is there an easier way to do this do I really need
00:34:44.770
this gym and when it comes to testing I'm always thinking first what's the
00:34:50.200
minimum amount of code I can get to verify that this works and if you're
00:34:55.450
practicing test-driven development that's a big deal when you're designing because you're starting off with a test
00:35:00.490
that is eat something that is easy to test so we're eliminating the
00:35:06.370
unnecessary so that the necessary may speak so when should you switch
00:35:15.710
I don't recommend that you switch all your existing code that you have now
00:35:21.640
especially if you think is going to magically make your test run faster because it's not just try it on your
00:35:28.070
next project see how you like it if you're using rails and test unit
00:35:34.869
eventually rails is going to switch for you because in the rails master branch Aaron Patterson went through and deleted
00:35:42.430
replace all occurrences of a required test unit with required many tests there
00:35:50.570
is a rails cast pro episode that's really good like think less than 15 minutes long but he'll show you some
00:35:57.349
really basic stuff about it and how easy it is to incorporate into a rails project so despite this being a test
00:36:08.960
framework specific talk I really don't want to argue that it's better than any
00:36:14.000
other test framework because I think that's largely based on taste which I don't think is a winnable debate but i
00:36:20.990
think is good about having a debate is that I get to hear a lot of different people's perspective and hearing
00:36:26.359
different people's perspective is always a good thing so I'm not going to tell
00:36:31.760
you that you should be using many tests or any other test framework for that matter if cucumber is quote/unquote
00:36:38.060
simple for you please by all means use cucumber I'm not even going to tell you
00:36:44.780
whether you should be using test unit style or spec style in fact if you
00:36:50.000
really want to use both at the same time this is perfectly valid runnable code
00:36:55.510
you can use an it block and use an assertion inside it and you can go ahead
00:37:01.130
and define a test underscore method and use spec expectations this is completely runnable code mini test goes both ways
00:37:14.140
so the good thing about us having the debate is that it shows that we really
00:37:19.550
care about testing and that's a big deal and I think it's about time that we throw a mini test into that conversation
00:37:27.340
but whatever you end up choosing to use whatever you do in your code please just
00:37:32.510
remember keep it simple once again my name is Jared ding you can find me at
00:37:39.710
reading gcom this was actually my first talk and I totally had a blast putting
00:37:45.590
it together if your if you want to go to speaker rate calm and give me some
00:37:51.140
feedback I'd really appreciate it that's it thanks a lot
00:38:48.619
member