00:00:27.200 --> 00:00:30.940 Just running a that's improve real quick.
00:00:31.110 --> 00:00:31.260 OK.
00:00:31.900 --> 00:00:32.100 Yeah.
00:00:33.140 --> 00:00:35.480 Do I have files name?
00:00:35.610 --> 00:00:40.494 Yes, that would be enough, because we don't do that part
00:00:40.494 --> 00:00:41.180 yet, OK.
00:00:56.890 --> 00:01:00.882 It opened it on my main monitor as I went over here one second
00:01:00.882 --> 00:01:02.340 since they will let me.
00:01:07.860 --> 00:01:08.340 That help?
00:01:11.750 --> 00:01:14.460 I told him to switch screens and it just killed it.
00:01:18.610 --> 00:01:20.190 Yeah, I have to say that's par for the course.
00:01:22.220 --> 00:01:24.430 Yeah, the dev environment process is just gone.
00:01:31.780 --> 00:01:35.352 So I guess I'll wait for it to spin up first before I pull it
00:01:35.352 --> 00:01:35.640 over.
00:01:50.310 --> 00:01:53.840 Right, this is a copy of the release 23.1.
00:01:54.350 --> 00:01:55.700 You haven't actually pulled on it.
00:01:55.810 --> 00:01:56.470 Let me pull.
00:02:00.690 --> 00:02:02.470 OK, it's up to date. Uh.
00:02:05.340 --> 00:02:08.792 Umm, I have the stuff config files in there and I haven't
00:02:08.792 --> 00:02:11.530 really done anything else with this instance.
00:02:25.290 --> 00:02:29.470 For the recording, I'm going to go ahead and open this and show
00:02:29.470 --> 00:02:31.560 the extensions I have installed.
00:02:35.990 --> 00:02:41.707 Though the online assignments Tavernier code made every guide
00:02:41.707 --> 00:02:42.260 lions.
00:02:45.360 --> 00:02:45.770 Indent.
00:02:45.780 --> 00:02:46.010 Rainbow.
00:02:47.890 --> 00:02:48.970 That's at Microsoft one.
00:02:49.640 --> 00:02:50.340 Oop not too far.
00:02:51.750 --> 00:02:53.790 Uh official city codes.
00:02:53.800 --> 00:02:57.055 Nice productivity power tools and installed a bunch of these
00:02:57.055 --> 00:02:58.550 other ones when you pick it.
00:02:59.240 --> 00:03:01.847 This gives it an option to page for some of the things that
00:03:01.847 --> 00:03:03.020 don't have them into there.
00:03:04.130 --> 00:03:06.740 Run as admin, they're just templates.
00:03:08.560 --> 00:03:10.891 This one I'm working on right now because I don't know why it
00:03:10.891 --> 00:03:11.380 doesn't work.
00:03:12.710 --> 00:03:13.240 Umm.
00:03:13.510 --> 00:03:17.542 But I'm gonna get fixed and then the the chief four language one
00:03:17.542 --> 00:03:21.077 by Brice Lambson gives you syntax highlighting and at 4,
00:03:21.077 --> 00:03:22.380 which is really nice.
00:03:22.390 --> 00:03:22.700 So it can.
00:03:22.710 --> 00:03:23.570 It's just black and white.
00:03:23.580 --> 00:03:24.290 You can actually read it.
00:03:23.680 --> 00:03:25.510 Hello yeah.
00:03:27.630 --> 00:03:29.550 This is a new one I'm dealing with.
00:03:29.560 --> 00:03:32.540 I'm trying to figure out what's wrong with this extension
00:03:32.540 --> 00:03:35.880 because I'm doing it with seven stuff and it's not working, so I
00:03:35.880 --> 00:03:38.860 have a request into the Git not 87 version of it created.
00:03:39.390 --> 00:03:42.863 Trying specializer and then the color output twisted explore the
00:03:42.863 --> 00:03:45.908 really good ones, but that's everything I have installed
00:03:45.908 --> 00:03:48.740 besides the Resharper and then Resharper extensions.
00:03:50.500 --> 00:03:54.840 I have get some of this may impact testing.
00:04:00.090 --> 00:04:00.370 Come on.
00:04:02.490 --> 00:04:06.170 If all of these installed heat that it doesn't have a wide
00:04:06.170 --> 00:04:09.974 enough border, not complete reshaper helpers, async apostle,
00:04:09.974 --> 00:04:13.280 external annotations, blah blah blah blah blah blah.
00:04:14.060 --> 00:04:17.397 Umm, there are other ones that I had tried using in the past but
00:04:17.397 --> 00:04:19.810 I just I don't use them but I don't need them.
00:04:20.060 --> 00:04:22.607 That stylecop 1 conflicts with the one that we use now, so
00:04:22.607 --> 00:04:23.600 don't install that one.
00:04:24.520 --> 00:04:28.535 Uh, it's based upon like the old 6.1 library, which we're using
00:04:28.535 --> 00:04:32.300 much more modern version of that with what we're doing now.
00:04:32.630 --> 00:04:35.610 And then this was their T4 syntax highlighting one, but it
00:04:35.610 --> 00:04:37.580 does not work right and it freaks out.
00:04:37.750 --> 00:04:38.590 So don't use that one.
00:04:39.880 --> 00:04:40.310 Umm.
00:04:42.170 --> 00:04:45.726 And then they think apostle is better than async converter
00:04:45.726 --> 00:04:46.690 async converter.
00:04:46.700 --> 00:04:49.836 I think they stopped supporting it or something, but Acosta does
00:04:49.836 --> 00:04:52.923 a better job of converting async code and letting you know like
00:04:52.923 --> 00:04:55.480 you missed your configure await and stuff like that.
00:04:57.920 --> 00:05:02.374 So those make extensions installed and then what are the
00:05:02.374 --> 00:05:07.063 things you usually have to do with the unit tests is to get
00:05:07.063 --> 00:05:11.830 into the settings of its uh, which you can't get from there.
00:05:11.840 --> 00:05:16.498 You have to go to options and then you can go down to unit
00:05:16.498 --> 00:05:17.130 testing.
00:05:17.200 --> 00:05:20.710 General, you can leave these on automatic.
00:05:21.850 --> 00:05:24.490 The 14 is is, you know, or 16 whatever.
00:05:24.500 --> 00:05:27.240 How is how many cores you have on your computer?
00:05:27.980 --> 00:05:30.887 If you wanna tune that down, it will leave a little more
00:05:30.887 --> 00:05:34.101 resources on your computer for other things that you're trying
00:05:34.101 --> 00:05:37.315 to do in the background while tests are running, especially if
00:05:37.315 --> 00:05:40.426 you're doing a build test, run a thousands of tests, it will
00:05:40.426 --> 00:05:43.487 leave more CPU available for other stuff to go on and these
00:05:43.487 --> 00:05:46.751 things a lot of these things are already built into the the dot
00:05:46.751 --> 00:05:48.690 settings that are at the root of CEF.
00:05:49.320 --> 00:05:51.630 That's what these settings files are.
00:05:51.640 --> 00:05:54.100 Is all of that stuff preconfigured and pushed into
00:05:54.100 --> 00:05:54.390 there?
00:05:54.560 --> 00:05:58.250 As best you can, and next is the test runner.
00:05:58.340 --> 00:06:00.280 It's got advanced on it by default.
00:06:00.290 --> 00:06:02.791 You actually want that to be none, and I keep forgetting to
00:06:02.791 --> 00:06:04.000 actually push that into core.
00:06:05.430 --> 00:06:08.607 But when you change a setting on here, you could say save 2 and
00:06:08.607 --> 00:06:11.685 say team shared and it will save it in that dot settings file
00:06:11.685 --> 00:06:13.720 which is included in the source control.
00:06:14.030 --> 00:06:17.240 So if I open the commit window here.
00:06:17.990 --> 00:06:20.510 Uh, that cause it's not relevant?
00:06:21.860 --> 00:06:24.292 I could double click this and then you could see that it has
00:06:24.292 --> 00:06:25.010 changed this file.
00:06:27.140 --> 00:06:29.750 Uh to say instead of advanced, it says none right here.
00:06:30.120 --> 00:06:33.070 So like, that's the shadow copy, two setting or whatever.
00:06:33.110 --> 00:06:34.970 I don't know what this other one here is, what it looks like.
00:06:34.980 --> 00:06:37.290 It's just another thing, Cortez.
00:06:37.300 --> 00:06:40.903 She was testing whatever, just the setting that wanted to save,
00:06:40.903 --> 00:06:42.930 but I'll close that for the moment.
00:06:43.140 --> 00:06:44.390 And what did I change here?
00:06:47.600 --> 00:06:48.430 You're relevant.
00:06:48.660 --> 00:06:49.080 Revert.
00:06:50.950 --> 00:06:51.150 OK.
00:06:52.140 --> 00:06:58.674 And so from the settings again we go to Resharper options test
00:06:58.674 --> 00:06:59.400 runner.
00:06:59.490 --> 00:07:02.240 You wanna make sure that that is on none, because the shadow copy
00:07:02.240 --> 00:07:03.240 does not work correctly.
00:07:03.480 --> 00:07:08.021 What that does is while you're typing and doing stuff, if you
00:07:08.021 --> 00:07:12.561 have running code coverage on things, it will have copied the
00:07:12.561 --> 00:07:17.102 DLLS and stuff that you would it was using to run the test to
00:07:17.102 --> 00:07:21.643 another location that didn't like your your I app data folder
00:07:21.643 --> 00:07:26.184 like over underneath your user in the hidden stuff like under
00:07:26.184 --> 00:07:26.550 here.
00:07:27.160 --> 00:07:30.729 Umm, but those paths break because it's trying to like use
00:07:30.729 --> 00:07:32.120 relative paths to find.
00:07:32.130 --> 00:07:34.978 Like your your solution items settings and your connection
00:07:34.978 --> 00:07:36.330 strings and stuff like that.
00:07:36.380 --> 00:07:39.113 And it is a copy of that stuff in there, and there's no way to
00:07:39.113 --> 00:07:39.590 tell it to.
00:07:40.220 --> 00:07:41.650 So it just breaks.
00:07:42.360 --> 00:07:44.900 So you want to leave that off so that it's always running
00:07:44.900 --> 00:07:46.390 directly off of your source code?
00:07:46.400 --> 00:07:52.416 That's been compiled and we we generally only use uh X unit for
00:07:52.416 --> 00:07:56.270 our unit tests in this version of stuff.
00:07:56.360 --> 00:08:00.034 And the new stuff we're currently switched over to in
00:08:00.034 --> 00:08:04.049 unit because it has better net core support and some other
00:08:04.049 --> 00:08:06.090 features that are streamlined.
00:08:06.100 --> 00:08:09.761 So we will be switching to the unit in Phoenix, but for now we
00:08:09.761 --> 00:08:11.970 are still on xunit on the main stuff.
00:08:12.120 --> 00:08:14.565 You don't need to fight a custom configuration file or anything
00:08:14.565 --> 00:08:15.750 or do anything with this stuff.
00:08:15.760 --> 00:08:19.448 You just run it with the metadata and that stuff right
00:08:19.448 --> 00:08:19.850 there.
00:08:21.240 --> 00:08:24.550 OK, so all of that to open the test runner.
00:08:24.680 --> 00:08:28.819 I rarely use the built in test runner and that's like only if I
00:08:28.819 --> 00:08:33.022 actually like don't have access to Resharper on whatever box I'm
00:08:33.022 --> 00:08:33.410 using.
00:08:33.640 --> 00:08:36.240 So when you open the test, if you don't have SharePoint
00:08:36.240 --> 00:08:39.259 installed, or even if you do and you were to open this one, this
00:08:39.259 --> 00:08:41.952 would be the default view that you would see for the test
00:08:41.952 --> 00:08:42.370 explorer.
00:08:42.800 --> 00:08:45.698 It's discovering right now because it hasn't built
00:08:45.698 --> 00:08:46.210 anything.
00:08:46.740 --> 00:08:49.319 If I control shift B to build, let's see if it needs to
00:08:49.319 --> 00:08:50.010 actually build.
00:08:50.210 --> 00:08:53.270 Looks like it might need to build some stuff.
00:08:57.070 --> 00:09:00.379 The net usually it's after it is built that it will figure out
00:09:00.379 --> 00:09:02.270 you know what it what it has there.
00:09:03.440 --> 00:09:04.470 Uh, yeah, there goes now.
00:09:04.480 --> 00:09:09.254 It start to pick up that there are tests UM 4913, not run uh
00:09:09.254 --> 00:09:12.150 just in the data model like testing.
00:09:12.300 --> 00:09:13.700 Uh, they're not.
00:09:13.710 --> 00:09:16.725 They don't, but just in the ecrs testing project, which is where
00:09:16.725 --> 00:09:19.648 all of that is, there are other projects that are not included
00:09:19.648 --> 00:09:20.390 in the solution.
00:09:20.700 --> 00:09:22.948 They were four other experimental stuff so that we
00:09:22.948 --> 00:09:25.240 could figure out if we were doing things correctly.
00:09:27.960 --> 00:09:32.686 What is for like uh answering and the selenium tests from
00:09:32.686 --> 00:09:37.656 their side, IED files converted into like exists feature and
00:09:37.656 --> 00:09:42.300 with all that those things you know built up everything.
00:09:42.390 --> 00:09:45.081 It had never got to fruition because we just haven't focused
00:09:45.081 --> 00:09:46.140 on that kind of testing.
00:09:46.580 --> 00:09:47.640 Hey, James.
00:09:46.730 --> 00:09:49.166 There's another one that's like alternate for Oracle and go
00:09:49.166 --> 00:09:49.410 ahead.
00:09:50.130 --> 00:09:50.930 Uh, I don't know.
00:09:50.940 --> 00:09:53.197 It just me, but your voice is getting a little bit like
00:09:53.197 --> 00:09:53.640 choppy, uh.
00:09:53.650 --> 00:09:54.430 Anybody else hearing that?
00:09:56.940 --> 00:09:57.910 Might just be my headset.
00:09:58.480 --> 00:09:59.020 Yeah, I'm here.
00:09:58.630 --> 00:09:59.450 No, it's.
00:09:59.870 --> 00:10:01.070 Yeah, it's cutting in and out.
00:10:00.030 --> 00:10:00.490 OK, OK.
00:10:00.560 --> 00:10:01.150 It's me.
00:10:03.030 --> 00:10:03.580 Oh, I see.
00:10:03.640 --> 00:10:03.890 I see.
00:10:03.900 --> 00:10:04.370 OK, yeah.
00:10:05.870 --> 00:10:15.080 And let me take this off of my uh, broadcast AI.
00:10:16.880 --> 00:10:17.250 Uh.
00:10:17.520 --> 00:10:21.520 Microphone to direct and that should be better once it.
00:10:21.530 --> 00:10:23.920 If I try to build again, you'll hear more background noise
00:10:23.920 --> 00:10:26.188 because it's not getting filtered out, but hopefully it
00:10:26.188 --> 00:10:27.930 won't make it so you can't hear me at all.
00:10:29.500 --> 00:10:32.460 OK, so where did I start breaking up?
00:10:35.190 --> 00:10:36.520 Somewhere near the beginning, I think.
00:10:36.490 --> 00:10:39.800 I could I could understand 90% of what you're saying.
00:10:39.810 --> 00:10:42.560 It was just very choppy and it would have been really.
00:10:41.350 --> 00:10:43.960 Yeah, it was only like the last couple of minutes or so.
00:10:42.610 --> 00:10:43.140 Yeah.
00:10:43.230 --> 00:10:44.100 I I just.
00:10:44.110 --> 00:10:46.449 I didn't realize you were building and it's already done
00:10:46.449 --> 00:10:48.460 building and fine, so it's probably not too bad.
00:10:48.510 --> 00:10:50.714 I just wanted to make sure it wasn't gonna be like that for
00:10:50.714 --> 00:10:52.330 the whole recording, but we should be fine.
00:10:51.740 --> 00:10:52.000 OK.
00:10:52.970 --> 00:10:54.540 Umm, so last a couple of minutes.
00:10:55.390 --> 00:10:56.960 I hardly ever used this test runner.
00:10:57.630 --> 00:11:00.650 I only use it if I basically don't have access to Resharper,
00:11:00.650 --> 00:11:03.620 which might be like in a client box or something like that.
00:11:04.510 --> 00:11:08.079 So if you bring it up normally, guys who don't use Resharper for
00:11:08.079 --> 00:11:10.220 running the test, you'll see this guy.
00:11:10.410 --> 00:11:11.450 It'll come in here.
00:11:11.460 --> 00:11:13.190 You just right click and you can run the tests.
00:11:13.200 --> 00:11:15.840 You can right click a main section and it can do it.
00:11:15.850 --> 00:11:19.625 I don't know why it let's talk it over there, but run that, I
00:11:19.625 --> 00:11:23.461 can run this group of tests on here and they should execute or
00:11:23.461 --> 00:11:25.410 if they're ignored then it will.
00:11:25.420 --> 00:11:28.480 It will skip them and you can see.
00:11:30.370 --> 00:11:31.280 All this stuff go through.
00:11:33.300 --> 00:11:36.619 Often one of the tests in a class will be the one that has
00:11:36.619 --> 00:11:39.770 to bite the bullet and take longer because it's the one
00:11:39.770 --> 00:11:43.033 that's gonna gonna do all the like static classes getting
00:11:43.033 --> 00:11:45.340 initialized in memory of the app domain.
00:11:46.000 --> 00:11:47.570 Umm, you know, things like that.
00:11:47.720 --> 00:11:48.890 They again English like one of them.
00:11:48.900 --> 00:11:52.462 Just kind of eat it until the others are are are already and
00:11:52.462 --> 00:11:55.850 then the other ones run like Super Fastly 6 milliseconds.
00:11:56.580 --> 00:11:57.730 So you'll see something like that.
00:11:57.740 --> 00:12:01.780 Whenever you do a test, run each class in X unit.
00:12:02.590 --> 00:12:04.570 Uh is its own app domain.
00:12:04.580 --> 00:12:06.290 Whenever you're running multiple of them side by side.
00:12:06.300 --> 00:12:08.926 So if I were to run the Mapper and the models one side by side,
00:12:08.926 --> 00:12:11.387 this these three would go into one app domain and these two
00:12:11.387 --> 00:12:12.290 would go into another.
00:12:12.400 --> 00:12:15.705 So each one of these will have one test that will have to do
00:12:15.705 --> 00:12:17.980 all that static initialization of things.
00:12:19.250 --> 00:12:22.185 That's just kind of one of the things that happens inside
00:12:22.185 --> 00:12:24.310 xunit, I believe in unit is the same way.
00:12:24.420 --> 00:12:27.907 I have not actually physically tested that though, and the goal
00:12:27.907 --> 00:12:31.068 behind that I for xunit in them is basically just to help
00:12:31.068 --> 00:12:34.120 isolate tests and keep him from stepping on each other.
00:12:34.570 --> 00:12:38.064 IX unit is designed such that all tests that are marked as
00:12:38.064 --> 00:12:41.263 like a factor of theory can and should be able to run
00:12:41.263 --> 00:12:44.580 independently of each other without a particular order.
00:12:44.710 --> 00:12:47.561 And there's no way to enforce an order without actually like
00:12:47.561 --> 00:12:50.505 removing them from being their own tests and putting them into
00:12:50.505 --> 00:12:53.450 a single test that runs them in the order you want them to run
00:12:53.450 --> 00:12:53.590 in.
00:12:54.320 --> 00:12:55.690 And kind of thing.
00:12:55.960 --> 00:12:58.449 So that's kind of where some of this stuff in and where the
00:12:58.449 --> 00:13:01.104 architecture on this, you know kind of came about is because of
00:13:01.104 --> 00:13:02.930 the way xunit basically executes the tests.
00:13:03.760 --> 00:13:06.702 Umm, so you see here like it'll count up how many total seconds
00:13:06.702 --> 00:13:07.760 is spent on that stuff.
00:13:07.770 --> 00:13:10.871 Sometimes that stuff is really like overlapping, so like you
00:13:10.871 --> 00:13:14.176 could a total amount of like it would be closer to where if they
00:13:14.176 --> 00:13:17.481 were all run back to back versus some of them concurrently based
00:13:17.481 --> 00:13:20.481 on the number of processors you have or processing cores I
00:13:20.481 --> 00:13:21.040 should say.
00:13:23.160 --> 00:13:24.820 But you'll get a type.
00:13:24.830 --> 00:13:27.820 You'll get a list out in a probably stop and say something
00:13:27.820 --> 00:13:30.911 like 30 minutes, depending on how fast your computer is, how
00:13:30.911 --> 00:13:33.952 fast your hard drive is, your ram, your CPU, how many cores
00:13:33.952 --> 00:13:35.270 there are, all that stuff.
00:13:35.280 --> 00:13:37.793 So you'll get a different number depending on what your hardware
00:13:37.793 --> 00:13:38.180 specs are.
00:13:38.920 --> 00:13:43.712 Umm, when you come through here the providers and like the data
00:13:43.712 --> 00:13:45.210 model they all have.
00:13:45.220 --> 00:13:47.701 Like there's some certain specific tests here that will,
00:13:47.701 --> 00:13:48.790 like, do specific things.
00:13:48.980 --> 00:13:51.998 A lot of them are ignored because they're meant to like
00:13:51.998 --> 00:13:55.447 you, like live testing with real credentials just to prove that
00:13:55.447 --> 00:13:57.980 something still works at all that we don't do.
00:13:57.990 --> 00:14:01.048 Like every time there's a PR because it's not necessary like
00:14:01.048 --> 00:14:04.156 this one, the ship times one is only works with live data, so
00:14:04.156 --> 00:14:05.410 it's a little skip in it.
00:14:05.640 --> 00:14:08.867 I could double click it and it can open that file that has the
00:14:08.867 --> 00:14:12.146 the test in it and show me right to where the test is and I can
00:14:12.146 --> 00:14:13.580 see here that I have a fact.
00:14:13.890 --> 00:14:16.870 The fact is that that is saying that it is a test.
00:14:17.090 --> 00:14:20.856 We do not use theories at all because for a long time X units
00:14:20.856 --> 00:14:24.501 theory system with either the built in Test Explorer or the
00:14:24.501 --> 00:14:26.080 reach over one was broken.
00:14:27.480 --> 00:14:30.833 It would cause certain hang ups that you wouldn't be able to run
00:14:30.833 --> 00:14:34.237 things correctly, so it was easy to just skip it and just write a
00:14:34.237 --> 00:14:37.281 regular fact for everything instead and do it that way and
00:14:37.281 --> 00:14:40.428 and with the way some of the later architecture for the test
00:14:40.428 --> 00:14:43.677 became, which I'll explain in a bit and it was simpler to just
00:14:43.677 --> 00:14:46.360 never bother with a theory for that reason as well.
00:14:46.970 --> 00:14:49.588 But we have a skip on this one that says that it will not
00:14:49.588 --> 00:14:52.296 actually run the run the test even if you tell it to run it
00:14:52.296 --> 00:14:55.003 and it will give an information out that says what the skip
00:14:55.003 --> 00:14:57.170 message was was just only works with live data.
00:14:58.110 --> 00:15:00.775 So that's the reason that this test is skipped and that's why
00:15:00.775 --> 00:15:03.611 it's allowing that to happen and then that gets recorded into the
00:15:03.611 --> 00:15:04.600 logs of every test run.
00:15:06.040 --> 00:15:08.490 On the PR's and all that stuff as that stuff happens.
00:15:08.500 --> 00:15:12.096 So we see that in those tests that stuff got skipped outside
00:15:12.096 --> 00:15:15.810 of the providers and like the base level like these other ones
00:15:15.810 --> 00:15:19.288 that are just doing random stuff like it might be checking
00:15:19.288 --> 00:15:23.061 individual things or it might be enforcing certain requirements
00:15:23.061 --> 00:15:24.830 of like your models and stuff.
00:15:24.840 --> 00:15:29.044 For cyclization, there's the largely standard workflow test,
00:15:29.044 --> 00:15:30.630 which is about 4800 of.
00:15:31.060 --> 00:15:33.629 This is basically just doing CRUD operations against every
00:15:33.629 --> 00:15:33.890 table.
00:15:34.840 --> 00:15:36.370 Effectively using their workflows.
00:15:37.050 --> 00:15:40.591 The goal with this being that if you were to override or change
00:15:40.591 --> 00:15:43.746 something about how the upsert function works or the get
00:15:43.746 --> 00:15:47.121 function like the git by ID or get by key function works, it
00:15:47.121 --> 00:15:50.497 still needs to meet certain requirements so that the rest of
00:15:50.497 --> 00:15:53.430 the system doesn't have to worry about what you did.
00:15:53.440 --> 00:15:56.736 Changing and breaking something else for expecting how like a
00:15:56.736 --> 00:15:59.660 regular git or a regular upsert, was supposed to work.
00:16:00.400 --> 00:16:03.213 Umm, you can certainly customize and modify those things so that
00:16:03.213 --> 00:16:05.464 you could do have to do extra things you have to do
00:16:05.464 --> 00:16:07.974 modifications of the data besieging the data that came in
00:16:07.974 --> 00:16:08.970 from connect, whatever.
00:16:10.020 --> 00:16:12.923 Whatever you gotta do, but it still needs to fundamentally
00:16:12.923 --> 00:16:14.990 upsert needs to actually upsert the data.
00:16:15.400 --> 00:16:17.965 If it's completely skipping that and never saving anything
00:16:17.965 --> 00:16:20.530 because you because of what you wrote, that's gonna break.
00:16:20.540 --> 00:16:24.740 How other workflows interact with this workflow for things?
00:16:24.750 --> 00:16:27.509 So that's what we're testing for, is making sure that you
00:16:27.509 --> 00:16:30.458 didn't accidentally introduce a bug somewhere else because of
00:16:30.458 --> 00:16:32.170 how you treated this one on things.
00:16:32.740 --> 00:16:36.405 It's kind of the the if you were talking like Sun Zoo territory,
00:16:36.405 --> 00:16:39.958 knowing where your enemy isn't is just as important as knowing
00:16:39.958 --> 00:16:41.030 where the enemy is.
00:16:41.580 --> 00:16:45.219 If I know that the enemy is not or if I know the enemy being the
00:16:45.219 --> 00:16:48.465 that you are failing, location is not within the accounts
00:16:48.465 --> 00:16:51.880 tables, then I know that I that one's OK don't have to worry
00:16:51.880 --> 00:16:52.720 about that one.
00:16:52.730 --> 00:16:55.774 I can go focus on this other area where there is a problem
00:16:55.774 --> 00:16:59.127 kind of thing and it'll warn you ahead of time that what you did
00:16:59.127 --> 00:17:02.171 was causing a problem for something else and that you need
00:17:02.171 --> 00:17:05.060 to go back and rethink what you did and how you did it.
00:17:05.610 --> 00:17:08.192 Probably through, you know, office hours with myself or
00:17:08.192 --> 00:17:11.005 Brendan or whatever to kind of get get a good look at what's
00:17:11.005 --> 00:17:11.420 going on.
00:17:11.430 --> 00:17:14.584 That is an indication that something like that needs to
00:17:14.584 --> 00:17:17.400 happen to to come take care of what you're doing.
00:17:17.630 --> 00:17:20.372 So you most of these guys, you'll see that they're probably
00:17:20.372 --> 00:17:21.560 gonna be 1011 or 12 tests.
00:17:22.050 --> 00:17:25.816 The reason for the differences are inheritance of the name,
00:17:25.816 --> 00:17:27.950 little base and displayable base.
00:17:28.130 --> 00:17:31.125 Because I have a couple of extra tests that cover those, so the
00:17:31.125 --> 00:17:33.606 display will base like an account image type has the
00:17:33.606 --> 00:17:36.180 nimble based test and it has a displayable based test.
00:17:36.190 --> 00:17:39.333 If I double click that displayable taste test, you can
00:17:39.333 --> 00:17:42.761 see that I have an architecture here where this is actually
00:17:42.761 --> 00:17:45.790 123456 separate tests that all run at the same time.
00:17:47.290 --> 00:17:51.125 Inside this single test that gets passed out, why am I doing
00:17:51.125 --> 00:17:51.440 that?
00:17:51.450 --> 00:17:52.300 That sounds crazy.
00:17:52.310 --> 00:17:53.120 What's wrong with you?
00:17:53.130 --> 00:17:56.100 How dare you do these things to confuse me and overload my CPU?
00:17:57.130 --> 00:18:00.053 It's because we have so many freaking tests in this entire
00:18:00.053 --> 00:18:00.400 system.
00:18:00.590 --> 00:18:05.559 Imagine this 12 times, not seven, but like 10, and then
00:18:05.559 --> 00:18:07.600 that many tests to run.
00:18:08.050 --> 00:18:09.520 It kind of overloads it.
00:18:10.070 --> 00:18:13.993 It does not like having 20,000 plus tests in there to work off
00:18:13.993 --> 00:18:14.180 of.
00:18:14.850 --> 00:18:17.120 Uh, on our on all these individual things.
00:18:17.210 --> 00:18:21.347 So instead we have combined a bunch of them so that we can
00:18:21.347 --> 00:18:25.275 take care of that and keep it from overloading the test
00:18:25.275 --> 00:18:28.080 runners with the sheer volume of tests.
00:18:28.290 --> 00:18:31.043 Does it make it a little harder to figure out which test is
00:18:31.043 --> 00:18:32.420 actually broken and the stuff?
00:18:32.490 --> 00:18:34.480 Yeah, like it's harder to debug it.
00:18:34.890 --> 00:18:38.415 I would say if you were running into a particular problem with a
00:18:38.415 --> 00:18:41.940 test that you knew that the path was within this test, you would
00:18:41.940 --> 00:18:43.350 break it out for a moment.
00:18:43.360 --> 00:18:46.241 You could just come in, do that, take care of whatever you gotta
00:18:46.241 --> 00:18:48.590 do, but your break points and stuff inside that guy.
00:18:48.720 --> 00:18:51.585 And then when you're done, you just revert this generated file
00:18:51.585 --> 00:18:54.313 back to the way it was after you fix whatever this thing is
00:18:54.313 --> 00:18:55.950 debugging that particular piece of.
00:18:57.530 --> 00:18:58.910 Piece of work problem.
00:18:58.920 --> 00:19:00.660 Whatever was was was happening with it.
00:19:01.070 --> 00:19:03.300 And then you know it's it's done.
00:19:03.350 --> 00:19:06.807 You just put it back in place by reverting the file and you're
00:19:06.807 --> 00:19:07.850 good to go on that.
00:19:07.860 --> 00:19:08.400 Kind of thing.
00:19:09.040 --> 00:19:11.320 What kind of tests are we testing and running inside the
00:19:11.320 --> 00:19:12.280 standard workflow tests?
00:19:12.490 --> 00:19:13.930 By golly, we have so many.
00:19:14.660 --> 00:19:18.934 Umm, there is a base class that is abstract that inherits a a
00:19:18.934 --> 00:19:23.209 further base class that tells what all the tests are and then
00:19:23.209 --> 00:19:27.346 basically just implement some information about like how to
00:19:27.346 --> 00:19:31.620 build a model up, how to build the database appropriately for
00:19:31.620 --> 00:19:32.310 this test.
00:19:33.050 --> 00:19:34.720 Umm, what kind of information?
00:19:34.730 --> 00:19:35.300 Like, what's the?
00:19:35.350 --> 00:19:37.650 What's the table that this this actually tries to read?
00:19:37.660 --> 00:19:40.535 So we can use it dynamically without having to worry about
00:19:40.535 --> 00:19:41.900 figuring out where stuff is.
00:19:43.270 --> 00:19:46.750 You know, reducing the amount of things are actually different
00:19:46.750 --> 00:19:50.285 from the T4 outputs that we're in and and otherwise how does it
00:19:50.285 --> 00:19:51.280 make a good model?
00:19:51.290 --> 00:19:53.780 So in order that would be valid to enter into the database.
00:19:54.550 --> 00:19:55.220 That kind of thing.
00:19:55.230 --> 00:19:57.852 So it builds all of this stuff out for us, and then we can
00:19:57.852 --> 00:19:59.230 actually override this further.
00:19:59.240 --> 00:20:02.235 So like if this if the T4 generator wasn't good enough, we
00:20:02.235 --> 00:20:05.078 can actually overwrite that ourselves in a special file
00:20:05.078 --> 00:20:08.277 which I'll show an example of shortly and of that with further
00:20:08.277 --> 00:20:11.221 extend this so that we could take the model that the base
00:20:11.221 --> 00:20:13.100 built and add more properties to it.
00:20:13.150 --> 00:20:16.366 It would make it more valid for entering into the database for
00:20:16.366 --> 00:20:19.736 custom requirements or whatever, and you'll see that the standard
00:20:19.736 --> 00:20:21.370 workflow tests inherit this guy.
00:20:21.600 --> 00:20:25.692 So if I collapse all here, you can see that Ohly shorten this
00:20:25.692 --> 00:20:26.550 guy up a bit.
00:20:27.650 --> 00:20:31.220 That this guy, it takes that guy in and drops it in.
00:20:31.610 --> 00:20:35.027 You also notice this constructor here has what's called an itest
00:20:35.027 --> 00:20:37.760 output helper that comes out of the X unit library.
00:20:37.990 --> 00:20:40.589 What that does is it basically makes it so that instead of
00:20:40.589 --> 00:20:43.277 using the console for stuff, it will actually spin it out to
00:20:43.277 --> 00:20:44.070 your outcome here.
00:20:44.780 --> 00:20:47.925 Umm on this stuff so that you can get the information about
00:20:47.925 --> 00:20:51.280 like what's going on inside the test or like why things failed.
00:20:52.200 --> 00:20:54.360 You know it debugging information during your test.
00:20:54.370 --> 00:20:54.810 Whatever.
00:20:54.880 --> 00:20:57.151 Instead of spinning to the console, you'll get to the test
00:20:57.151 --> 00:20:57.690 output helper.
00:20:57.860 --> 00:21:01.129 That way you can get outside here and there, and it's easily
00:21:01.129 --> 00:21:04.452 digestible at place to look at your information, I can show a
00:21:04.452 --> 00:21:06.650 couple of examples of that to you later.
00:21:07.250 --> 00:21:10.546 Umm, so you have to pass that into the constructor because
00:21:10.546 --> 00:21:13.953 it's dynamically injected and then I have that down into the
00:21:13.953 --> 00:21:17.249 base here so that the base the most base level one if they
00:21:17.249 --> 00:21:19.260 follow this chain all the way down.
00:21:19.270 --> 00:21:22.724 South the table base Displayable based annual base and then all
00:21:22.724 --> 00:21:26.070 the way down to just base umm this is where the base dropped.
00:21:26.580 --> 00:21:29.639 Lol And then it puts it into there and that it inherits the
00:21:29.639 --> 00:21:32.902 xunit log helper which basically just puts it in there and then
00:21:32.902 --> 00:21:35.859 basically and like loads up some stuff and perhaps it for
00:21:35.859 --> 00:21:37.950 starting up so that we had access to it.
00:21:38.120 --> 00:21:40.078 And then when you're writing into this, it's kind of like
00:21:40.078 --> 00:21:42.070 running with a string builder or writing with the console.
00:21:42.080 --> 00:21:45.220 You just do write line and then you spit him wherever you want.
00:21:45.230 --> 00:21:45.460 You can.
00:21:45.470 --> 00:21:48.902 It could take a message format, so you could say like this
00:21:48.902 --> 00:21:50.880 failed zero and then you pass in.
00:21:50.940 --> 00:21:56.648 You know, whatever object you want new something equal to
00:21:56.648 --> 00:21:57.140 four.
00:21:58.660 --> 00:21:59.310 Hey James.
00:21:58.940 --> 00:21:59.320 I don't know.
00:21:59.320 --> 00:22:00.450 Sorry to interrupt you.
00:22:00.460 --> 00:22:02.380 Can you zoom in a little bit on the text?
00:22:05.720 --> 00:22:06.060 How's that?
00:22:06.050 --> 00:22:06.470 Perfect.
00:22:06.870 --> 00:22:07.200 Great.
00:22:07.210 --> 00:22:07.540 Thank you.
00:22:08.340 --> 00:22:12.227 OK, so you can actually like you could take it a template into it
00:22:12.227 --> 00:22:15.997 and have it automatically format arguments on there and it just
00:22:15.997 --> 00:22:19.590 takes it and so it's nice and happy then and you'll get your
00:22:19.590 --> 00:22:23.360 test output, you know, whatever you put in there, we'll show up
00:22:23.360 --> 00:22:26.070 inside here as part of whatever you're doing.
00:22:26.320 --> 00:22:28.830 I'll cut that back out and close that stuff out.
00:22:29.440 --> 00:22:32.670 Looking at the abstract base, it's got some basic extensions
00:22:32.670 --> 00:22:35.900 stuff like checking like the values of a self are so like if
00:22:35.900 --> 00:22:39.077 the sefar was supposed to have passed with no messages then
00:22:39.077 --> 00:22:42.572 this will go assert those things for you sooner to go write those
00:22:42.572 --> 00:22:43.790 individual lines again.
00:22:44.140 --> 00:22:44.730 Same thing here.
00:22:44.740 --> 00:22:47.363 If it's failed and it's supposed to have like a particular
00:22:47.363 --> 00:22:50.075 message on it because you're trying to test a negative path,
00:22:50.075 --> 00:22:51.720 you would assert that it's not null.
00:22:51.910 --> 00:22:55.911 The action C that would fall that there is a message that the
00:22:55.911 --> 00:22:59.913 message Matt you know was equal to whatever we we want, we're
00:22:59.913 --> 00:23:01.720 expecting to have come back.
00:23:02.690 --> 00:23:05.563 These asserts are all from the external library and the other
00:23:05.563 --> 00:23:06.860 libraries do the same thing.
00:23:07.210 --> 00:23:09.420 They might use a slightly different syntax, or a slightly
00:23:09.420 --> 00:23:11.820 different name for this stuff, but effectively the same thing.
00:23:11.830 --> 00:23:15.085 If you're just assert that something was not null or assert
00:23:15.085 --> 00:23:18.395 that this particular Boolean value was false, or assert that
00:23:18.395 --> 00:23:21.542 this collection of values only had one entry and and then
00:23:21.542 --> 00:23:25.015 assert that this that the first value equal to the second value
00:23:25.015 --> 00:23:28.162 whatever type it was, it will take it in automatically as
00:23:28.162 --> 00:23:29.030 different types.
00:23:29.520 --> 00:23:32.472 So if it's a string, or if it's a number or whatever, whatever
00:23:32.472 --> 00:23:35.378 you're expected value was to match whatever your actual value
00:23:35.378 --> 00:23:36.690 was and it will spit it out.
00:23:36.700 --> 00:23:40.460 If they're different, umm, on their stuff and then you can
00:23:40.460 --> 00:23:44.220 also do like a failure message that says in some of these.
00:23:44.640 --> 00:23:49.274 Umm uh, it looks like I can't do it there because my hockey got
00:23:49.274 --> 00:23:52.750 eaten and let's see, can't do it with that one.
00:23:53.710 --> 00:23:55.320 I should be able to do it with this one.
00:23:55.330 --> 00:23:56.720 I know that to be true one can do it here.
00:23:56.730 --> 00:23:57.640 That's why I have this.
00:23:57.730 --> 00:24:00.517 So in this case, like I was trying to assert that it was
00:24:00.517 --> 00:24:03.598 true if it was not true, I can build my own custom message for
00:24:03.598 --> 00:24:06.386 the error log that says what went wrong so that I have a
00:24:06.386 --> 00:24:08.440 better understanding of what to look for.
00:24:08.890 --> 00:24:12.299 So for in this case, because it's a set far, it usually is
00:24:12.299 --> 00:24:15.420 going to have a message inside it of what went wrong.
00:24:15.470 --> 00:24:18.567 So I'll take the messages and I'll say if it was empty, I'll
00:24:18.567 --> 00:24:21.563 do say no messages, otherwise I'll aggregate them together
00:24:21.563 --> 00:24:24.000 into a single string and split that out into a.
00:24:24.740 --> 00:24:26.170 My fair failure log.
00:24:26.220 --> 00:24:27.460 So you have your user message here.
00:24:28.490 --> 00:24:30.600 That is what your custom error message is for.
00:24:30.610 --> 00:24:33.687 For sending it out, if you leave it alone, it or blank or don't
00:24:33.687 --> 00:24:36.620 send it in like that, then all it will do is just say ohh it
00:24:36.620 --> 00:24:39.457 didn't match what you were supposed to do and it just give
00:24:39.457 --> 00:24:41.140 you like default messaging for it.
00:24:41.430 --> 00:24:44.496 But with this we know we have actually debugging info we can
00:24:44.496 --> 00:24:46.960 pass, so we pass it into our user message block.
00:24:47.010 --> 00:24:47.190 Here.
00:24:48.390 --> 00:24:51.778 And we have a do mocking setup which is basically to go to
00:24:51.778 --> 00:24:55.395 after you set up all the tables you're gonna put for your fake
00:24:55.395 --> 00:24:57.520 context, it's gonna exist in memory.
00:24:57.970 --> 00:25:00.879 It tells the to initialize the database and populate it with
00:25:00.879 --> 00:25:03.597 contents with that stuff, and I'll go over that as we go
00:25:03.597 --> 00:25:04.980 through the other stuff here.
00:25:05.650 --> 00:25:06.490 The do setup here.
00:25:07.790 --> 00:25:11.092 What this does is it does the do sucking the setup for the for
00:25:11.092 --> 00:25:14.290 the context it goes into the root container and replaces the
00:25:14.290 --> 00:25:17.592 logger so that whenever you were asking for the logger through
00:25:17.592 --> 00:25:20.947 our system, we get this object instance of an extra logger that
00:25:20.947 --> 00:25:24.250 instead of logging to a database or logging to a file, it uses
00:25:24.250 --> 00:25:27.500 our test output helper so that it will write to our log here.
00:25:28.010 --> 00:25:29.610 That allows us to basically do any time.
00:25:29.620 --> 00:25:30.900 There's a log or anything going on.
00:25:30.910 --> 00:25:33.525 We get that output into our output log here, and it's easy
00:25:33.525 --> 00:25:36.361 to find and see whether having to go hunt it down or like debug
00:25:36.361 --> 00:25:38.976 the test directly to find that information, which makes it
00:25:38.976 --> 00:25:40.970 really convenient for that particular issue.
00:25:42.270 --> 00:25:45.937 We also go in and add that anytime we ask for the database,
00:25:45.937 --> 00:25:49.727 we use our mock setup context and then anytime that we add or
00:25:49.727 --> 00:25:53.761 we also add into the registry of data model testing registry that
00:25:53.761 --> 00:25:57.490 says that it needs to create like a new entity record in the
00:25:57.490 --> 00:25:58.040 database.
00:25:58.470 --> 00:26:01.575 It knows how to do that with our interfaces and our concretes
00:26:01.575 --> 00:26:04.729 that are done in our data model layer and that's what this one
00:26:04.729 --> 00:26:04.980 does.
00:26:04.990 --> 00:26:08.124 This is at 4 generated output that if we go through and look
00:26:08.124 --> 00:26:11.463 at like what create registry for accounts you can see like for a
00:26:11.463 --> 00:26:12.080 new account.
00:26:12.920 --> 00:26:16.020 This is what it builds out for the account and how how to talk
00:26:16.020 --> 00:26:19.170 to the fake tables as it talks to stuff so that we can continue
00:26:19.170 --> 00:26:21.827 manipulating properties, manipulating things that are
00:26:21.827 --> 00:26:24.780 related to other things are associated to other things from
00:26:24.780 --> 00:26:27.831 our entity records and they all basically works as far as the
00:26:27.831 --> 00:26:30.784 testing is concerned, even though it's actually attached to
00:26:30.784 --> 00:26:33.687 a real database thing that entity framework would be using
00:26:33.687 --> 00:26:34.770 to talk to for things.
00:26:34.780 --> 00:26:38.433 So this is basically faking it all out while making it somewhat
00:26:38.433 --> 00:26:41.800 still functional against our fake database, and that stuff
00:26:41.800 --> 00:26:43.170 gets really complicated.
00:26:43.210 --> 00:26:44.310 Not gonna spend too much time on it?
00:26:44.730 --> 00:26:48.460 Umm what it is or why it is on that, but I I will go over some
00:26:48.460 --> 00:26:51.894 more here and then it will override the regular container
00:26:51.894 --> 00:26:55.447 with this child container and I'll explain that in a moment
00:26:55.447 --> 00:26:59.296 when I get into the actual test of what that's doing so that the
00:26:59.296 --> 00:27:02.848 the that that that's what the context profile names are for
00:27:02.848 --> 00:27:06.283 will is it to have like a trainers work and so it's gonna
00:27:06.283 --> 00:27:09.776 create this child container in there and then it will pass
00:27:09.776 --> 00:27:13.092 through the test that's being executed this the context
00:27:13.092 --> 00:27:16.763 profile name with that name so that it uses instead of a live
00:27:16.763 --> 00:27:20.079 one which would use a real logger it uses this fake one
00:27:20.079 --> 00:27:23.750 that just goes in and operates against the test output helper
00:27:23.750 --> 00:27:27.184 and anything else that we've mocked and set up inside our
00:27:27.184 --> 00:27:29.020 registry for dynamic injection.
00:27:30.090 --> 00:27:32.435 So after that we kind of get into one of our first actual
00:27:32.435 --> 00:27:32.880 tests here.
00:27:33.050 --> 00:27:37.399 So we have the get ID async or OK, this isn't the test, this is
00:27:37.399 --> 00:27:39.710 getting gathering data for stuff.
00:27:39.750 --> 00:27:42.842 So some of the tests will be like what I need to verify that
00:27:42.842 --> 00:27:45.630 the first record I pull is gonna have a particular ID.
00:27:45.820 --> 00:27:49.122 Well, that ID might be set up weird inside the do mucking
00:27:49.122 --> 00:27:52.880 setup for context runners, which is where all of our fake data is
00:27:52.880 --> 00:27:53.450 built out.
00:27:53.540 --> 00:27:58.411 So like the do MMS FCR do mocking setup for context Runner
00:27:58.411 --> 00:27:59.650 for an account.
00:27:59.900 --> 00:28:03.672 The first one might have been 100 instead of 1, so it goes and
00:28:03.672 --> 00:28:04.930 just reads that data.
00:28:04.940 --> 00:28:09.400 That raw data out of the array that gets put in here, or a list
00:28:09.400 --> 00:28:11.770 of whatever it is and it goes OK.
00:28:11.780 --> 00:28:14.034 So the first ID should be 100, so that's what you should expect
00:28:14.034 --> 00:28:14.880 to see inside your test.
00:28:14.890 --> 00:28:18.728 If you're looking for the first one, same thing for grabbing the
00:28:18.728 --> 00:28:22.507 key of it, the name of it, the description of it, whatever, and
00:28:22.507 --> 00:28:24.220 operating through that stuff.
00:28:24.410 --> 00:28:27.891 Is it just reading that raw data out of the table so the test
00:28:27.891 --> 00:28:30.250 knows what to look for inside that stuff?
00:28:31.960 --> 00:28:35.527 If I skip past a couple of those things, the mock set and the raw
00:28:35.527 --> 00:28:38.554 set, these are abstract properties or I'm sorry methods
00:28:38.554 --> 00:28:41.040 that the overload will get will take care of.
00:28:41.050 --> 00:28:43.190 Those are usually handled by the T4 overload.
00:28:43.200 --> 00:28:46.790 They could be further overloaded manually in special files.
00:28:46.800 --> 00:28:49.325 If you need to, but generally speaking you'll just step
00:28:49.325 --> 00:28:51.670 through those things and you'll operate that stuff.
00:28:51.880 --> 00:28:53.190 I'm going to go through these guys.
00:28:53.200 --> 00:28:58.793 I'm going to kind of skip down and move on to where the first
00:28:58.793 --> 00:29:01.410 get by ID should return blah.
00:29:04.340 --> 00:29:06.820 Where's a good one that actually has stuff in it?
00:29:07.000 --> 00:29:07.530 There you go.
00:29:07.540 --> 00:29:07.990 That's the.
00:29:08.000 --> 00:29:08.950 Here's the first real test.
00:29:10.500 --> 00:29:14.893 So what we do is we build a context profile name which is
00:29:14.893 --> 00:29:16.560 the name of this test.
00:29:17.460 --> 00:29:17.780 Uh.
00:29:17.790 --> 00:29:21.370 Which I should actually do like name of instead of that.
00:29:23.480 --> 00:29:26.336 Boom, now that it has, this gets refactored with a different
00:29:26.336 --> 00:29:26.570 name.
00:29:26.580 --> 00:29:30.522 It'll update that button to rather than just ignoring it
00:29:30.522 --> 00:29:34.742 because it was a string we pass in the name of the test, and
00:29:34.742 --> 00:29:39.168 then we go over to this guy and it builds in the type that this
00:29:39.168 --> 00:29:40.690 is being inherited to.
00:29:40.820 --> 00:29:44.799 So like if it's the accounts one, the account workflow tests,
00:29:44.799 --> 00:29:48.779 it will say account, workflow test pipe and then the function
00:29:48.779 --> 00:29:52.758 name as it puts it in there and then returns that as a string
00:29:52.758 --> 00:29:56.416 for use in this guy's thing as the the the value to pass
00:29:56.416 --> 00:29:56.930 through.
00:29:57.150 --> 00:30:01.068 Then it creates a disposable child container which is part of
00:30:01.068 --> 00:30:04.923 our structure map di and that just kind of creates the child
00:30:04.923 --> 00:30:08.778 container and then inside that trial container we pass in we
00:30:08.778 --> 00:30:12.633 pass it over to the due setup async which we saw earlier and
00:30:12.633 --> 00:30:16.678 we create the blocking setup for this end expanded tables which
00:30:16.678 --> 00:30:20.280 the overridden T4 value has to inherit and **** care of.
00:30:20.530 --> 00:30:23.770 If I control F-12 that and go over to the accounts one.
00:30:26.100 --> 00:30:27.620 And I'll put these up side by side.
00:30:27.630 --> 00:30:30.026 You can kind of see what's going on with the different tiers of
00:30:30.026 --> 00:30:31.150 where this stuff is happening.
00:30:31.860 --> 00:30:35.946 Umm, all of these tables are required when you're doing extra
00:30:35.946 --> 00:30:37.330 stuff around account.
00:30:37.340 --> 00:30:40.610 It's not just like the account table itself, but it's gonna be
00:30:40.610 --> 00:30:40.870 real.
00:30:40.880 --> 00:30:43.990 It's got director associations or relationships with countries,
00:30:43.990 --> 00:30:47.101 currencies, franchises, nodes, vendors, users and some of those
00:30:47.101 --> 00:30:50.163 things have other requirements that aren't directly related by
00:30:50.163 --> 00:30:53.274 the account where the directly related by those things in order
00:30:53.274 --> 00:30:56.336 to interface with the thing that is interfacing with the thing
00:30:56.336 --> 00:30:59.203 which makes sense, which I'm sure wonderfully makes sense,
00:30:59.203 --> 00:31:02.071 it's basically just doing a little bit of a semi recursive
00:31:02.071 --> 00:31:04.987 reviews of some of the other tables that will have to touch
00:31:04.987 --> 00:31:07.320 in order to make the test here worked properly.
00:31:07.710 --> 00:31:11.176 And then again, because this is a virtual and is overwritten
00:31:11.176 --> 00:31:11.460 here.
00:31:11.710 --> 00:31:15.450 If there's more you have to add to this, you could further
00:31:15.450 --> 00:31:19.000 override it with a special workflow and add more to it.
00:31:19.230 --> 00:31:22.542 Now the accounts themselves, we do have an extended file here
00:31:22.542 --> 00:31:25.855 and this is where one of the cases where we do extend some of
00:31:25.855 --> 00:31:26.870 that stuff further.
00:31:26.950 --> 00:31:29.493 I'm extending this particular one, but I am extending like the
00:31:29.493 --> 00:31:30.220 create model look.
00:31:30.590 --> 00:31:33.759 So instead of just the whatever he had before, I'm also adding
00:31:33.759 --> 00:31:36.878 in not just that data, but I'm adding in account contact with
00:31:36.878 --> 00:31:39.998 like a fully fleshed out all the way down through the address
00:31:39.998 --> 00:31:42.010 with like a region and countries stuff.
00:31:42.960 --> 00:31:46.189 Whereas if I didn't include that information, the thing would
00:31:46.189 --> 00:31:49.158 probably go through, but it wouldn't exercise any of the
00:31:49.158 --> 00:31:51.190 account contexts association workflow.
00:31:51.370 --> 00:31:54.002 By doing this, I make it exercise those things and I get
00:31:54.002 --> 00:31:56.727 more of my test coverage, actually covering things to make
00:31:56.727 --> 00:31:59.682 sure they actually work because it is expected that you be able
00:31:59.682 --> 00:32:02.546 to include the account context with the account and have them
00:32:02.546 --> 00:32:04.670 flow all the way through the system on there.
00:32:04.680 --> 00:32:08.212 So I have my create hooked change and I have my update hook
00:32:08.212 --> 00:32:11.567 change where it has included additional information that
00:32:11.567 --> 00:32:15.158 would make other modifications and I'll go test those things
00:32:15.158 --> 00:32:17.160 later when I operate my my tests.
00:32:18.650 --> 00:32:20.410 So we are setting up our database.
00:32:21.210 --> 00:32:24.802 Uh, so that it's prepared to be to be populated or propagated
00:32:24.802 --> 00:32:28.452 with data we call the do setup async, which as we go back over
00:32:28.452 --> 00:32:30.770 here, this is the thing we saw earlier.
00:32:31.550 --> 00:32:34.826 It runs the mocking setup which actually populates the in memory
00:32:34.826 --> 00:32:35.280 database.
00:32:35.450 --> 00:32:38.632 It assigns all this stuff into our container and then it pushes
00:32:38.632 --> 00:32:41.714 the container into the registry loader so that it's available
00:32:41.714 --> 00:32:42.510 for other tests.
00:32:42.520 --> 00:32:45.538 To call anything on the registry for dynamic injection and it
00:32:45.538 --> 00:32:48.459 will use our instance of it as we operate through the test,
00:32:48.459 --> 00:32:49.920 I'll go back to where we were.
00:32:51.420 --> 00:32:55.350 So first we arrange we do the AAA stuff with all of our tests.
00:32:55.360 --> 00:32:56.570 Here we arrange.
00:32:56.910 --> 00:32:59.040 Then we act, and then we assert there.
00:32:59.300 --> 00:33:00.250 Arrange, act, assert.
00:33:00.380 --> 00:33:03.207 We try to we try to enforce that through all the tests that we
00:33:03.207 --> 00:33:05.675 kind of keeps them well organized and what we're doing
00:33:05.675 --> 00:33:08.143 and keeping in mind where stuff's going and what we're
00:33:08.143 --> 00:33:09.130 going to deal with it.
00:33:09.960 --> 00:33:12.739 So the first part is arranging building everything that the
00:33:12.739 --> 00:33:15.240 test is going to need in order to physically operate.
00:33:15.250 --> 00:33:18.756 What's going to do, and whether you're creating adding more
00:33:18.756 --> 00:33:22.320 steps to the box you're adding more, you know, fake eat into
00:33:22.320 --> 00:33:23.080 the database.
00:33:23.090 --> 00:33:25.736 Whether you're instantiating models with particular
00:33:25.736 --> 00:33:28.790 properties on them or you're creating a workflow and you're
00:33:28.790 --> 00:33:31.945 setting up the workflow that it has properties set so that it
00:33:31.945 --> 00:33:33.930 will impact how the workflow operates.
00:33:33.940 --> 00:33:37.174 Or you might be changing like SEF config dictionary settings
00:33:37.174 --> 00:33:40.354 or something like that so that they are ready for what this
00:33:40.354 --> 00:33:42.740 test is going to use them for on this stuff.
00:33:43.280 --> 00:33:46.825 Then you act, which is mostly the time gonna be like a one
00:33:46.825 --> 00:33:50.189 liner that will go go do this one thing and give me the
00:33:50.189 --> 00:33:50.610 result.
00:33:51.250 --> 00:33:54.137 And if it's a positive path, you're usually going to pull
00:33:54.137 --> 00:33:57.322 back a result, and then you'll go assert that result individual
00:33:57.322 --> 00:34:00.358 properties or values upon that thing to say like this had to
00:34:00.358 --> 00:34:03.195 have conformed to all these different things in order to
00:34:03.195 --> 00:34:04.240 have worked properly.
00:34:04.510 --> 00:34:08.755 So for instance, the first thing we're checking is did this
00:34:08.755 --> 00:34:13.001 result get back null because we expected this to get us the
00:34:13.001 --> 00:34:16.680 first a record in our mock database for this table.
00:34:17.110 --> 00:34:19.727 The first account which would have been account ID of one, we
00:34:19.727 --> 00:34:21.500 know that it was used to have an account.
00:34:21.510 --> 00:34:24.192 ID of one it was supposed to be in the data, so if this came
00:34:24.192 --> 00:34:25.380 back null that's a problem.
00:34:26.130 --> 00:34:29.769 So if you just change something in the git by ID workflow on
00:34:29.769 --> 00:34:33.050 accounts, then that made it so that it didn't find it.
00:34:33.130 --> 00:34:33.950 We know that that's a problem.
00:34:33.960 --> 00:34:34.460 That's gonna break.
00:34:34.470 --> 00:34:35.380 How other systems work?
00:34:35.530 --> 00:34:37.110 So that's the first thing we're checking.
00:34:37.150 --> 00:34:39.310 Then we check to make sure that is the correct type, like it was
00:34:39.310 --> 00:34:40.540 supposed to return an account model.
00:34:40.810 --> 00:34:43.566 If it returns something else that was custom, then this test
00:34:43.566 --> 00:34:46.097 is going to fail because you changed something that was
00:34:46.097 --> 00:34:48.808 fundamental for what the type was, because other things are
00:34:48.808 --> 00:34:51.519 going to assume that it was going to be in account model or
00:34:51.519 --> 00:34:54.230 I account model and make sure that the ID match that it did
00:34:54.230 --> 00:34:55.360 somehow get the wrong ID.
00:34:56.250 --> 00:34:58.418 We make sure that it was active because this should only be
00:34:58.418 --> 00:34:59.430 pulling back active records.
00:35:00.680 --> 00:35:03.588 We verified that the creative date on it matches this, that
00:35:03.588 --> 00:35:03.830 data.
00:35:03.920 --> 00:35:06.090 This is really just verifying that there was data on there.
00:35:06.100 --> 00:35:08.682 Generally speaking, and in this case we know the created date
00:35:08.682 --> 00:35:11.222 because we're setting them all to the same thing in our mock
00:35:11.222 --> 00:35:11.430 data.
00:35:11.520 --> 00:35:14.814 So we're just able to directly validate that the dates match
00:35:14.814 --> 00:35:18.001 updated date if it had been modified or any of this stuff,
00:35:18.001 --> 00:35:21.295 or the default data for these things is going to expect that
00:35:21.295 --> 00:35:24.535 it had not been modified on a get call and that the default
00:35:24.535 --> 00:35:27.560 data that was put in there didn't have an updated date.
00:35:27.570 --> 00:35:29.964 So it should still be null, so that's what it's checking for
00:35:29.964 --> 00:35:30.160 here.
00:35:30.630 --> 00:35:33.671 You had done some modification to the account record in your
00:35:33.671 --> 00:35:34.120 git call.
00:35:34.370 --> 00:35:38.178 That's not an ideal scenario, so we're calling it out here and
00:35:38.178 --> 00:35:41.200 then we verified that the custom key is the same.
00:35:41.510 --> 00:35:44.947 Then we go verify that some mobile base properties and some
00:35:44.947 --> 00:35:48.442 displayable phrase properties and then this one is our extra
00:35:48.442 --> 00:35:51.650 one that if we don't do anything, if we don't overwrite
00:35:51.650 --> 00:35:53.140 it, it's gonna do nothing.
00:35:53.250 --> 00:35:56.172 But if we do overwrite it, we can add an extra testing and
00:35:56.172 --> 00:35:57.410 validation and our stuff.
00:35:57.420 --> 00:35:59.350 I'll see if I can find something that actually overrides it.
00:36:00.200 --> 00:36:05.498 Looks like no on that one, and we'll see another one trying to
00:36:05.498 --> 00:36:08.610 find one that has an implementation.
00:36:09.940 --> 00:36:11.310 So I did.
00:36:14.250 --> 00:36:17.490 OK, here's one that actually has an implementation account.
00:36:17.500 --> 00:36:20.558 Price points override and they add an extra assertion so they
00:36:20.558 --> 00:36:23.617 take in the result that came back, which is the account price
00:36:23.617 --> 00:36:26.823 point model result and then they do like the slave ID was as was
00:36:26.823 --> 00:36:29.882 expected to be 4 for the data that they were working on there
00:36:29.882 --> 00:36:30.770 instead of ID one.
00:36:30.960 --> 00:36:33.988 So they come in and they modify and they do whatever and you can
00:36:33.988 --> 00:36:35.060 write any extra search.
00:36:35.070 --> 00:36:37.924 You want to do in that stuff in order to verify and validate
00:36:37.924 --> 00:36:40.918 data, probably directly related to you change the create or you
00:36:40.918 --> 00:36:41.760 change the update.
00:36:41.770 --> 00:36:44.365 You probably want to change what you're asserting, so you come in
00:36:44.365 --> 00:36:45.270 and you wrote it right.
00:36:45.280 --> 00:36:48.559 Overrides or extensions to the data, and there's hooks about
00:36:48.559 --> 00:36:51.945 come in and run automatically for you as part of this process,
00:36:51.945 --> 00:36:54.955 which helps a lot with, you know, verifying and getting
00:36:54.955 --> 00:36:58.502 through all the different things and then at the end of the test,
00:36:58.502 --> 00:37:01.942 now that everything's verified and good, as long as it got this
00:37:01.942 --> 00:37:05.329 far, the using here is going to dispose of the child container
00:37:05.329 --> 00:37:08.500 and then we tell the registered letter to remove the talk.
00:37:08.710 --> 00:37:11.402 That had this particular name out of memory so that we don't
00:37:11.402 --> 00:37:13.918 have a memory leak with our tests coming in and eating a
00:37:13.918 --> 00:37:14.580 bunch of stuff.
00:37:14.690 --> 00:37:16.420 Most of these tests function the same way.
00:37:16.430 --> 00:37:19.179 If they're a positive path, especially these, get by IDs get
00:37:19.179 --> 00:37:19.900 by key whatever.
00:37:19.990 --> 00:37:22.851 We're just arranging it by creating our stuff, running an
00:37:22.851 --> 00:37:25.810 action, and then we assert whatever particular actions that
00:37:25.810 --> 00:37:28.819 we have to do, there might be extra inherited hooks that you
00:37:28.819 --> 00:37:31.729 know, because because it's available base or a displayable
00:37:31.729 --> 00:37:34.738 base or custom stuff because we just put stuff in there that
00:37:34.738 --> 00:37:36.070 will do extra tests for us.
00:37:37.180 --> 00:37:39.180 But that's largely how these tests work.
00:37:40.080 --> 00:37:42.180 Any questions before I move into like a negative test?
00:37:50.100 --> 00:37:51.430 If anyone's talking, I can't hear him.
00:37:57.450 --> 00:38:00.295 Tell you what, everyone raise your hand if you're if you're OK
00:38:00.295 --> 00:38:01.740 for me to move forward that way.
00:38:01.740 --> 00:38:02.510 I know you're paying attention.
00:38:09.650 --> 00:38:12.230 OK, good.
00:38:12.240 --> 00:38:14.940 Alright, you can drop your hands and thank you.
00:38:15.610 --> 00:38:16.080 OK.
00:38:16.150 --> 00:38:19.060 So that's a positive test that would go in and do that stuff.
00:38:19.070 --> 00:38:20.150 Let's find a negative test.
00:38:21.090 --> 00:38:24.310 Umm, so we notice how we named it.
00:38:24.610 --> 00:38:26.560 Verify git by ID.
00:38:26.600 --> 00:38:29.310 Should return a model with a full map.
00:38:29.800 --> 00:38:30.240 Boom.
00:38:30.250 --> 00:38:32.223 We should do full mapping and we should do more full mapping
00:38:32.223 --> 00:38:32.450 checks.
00:38:33.090 --> 00:38:35.300 Here's a negative path that says instead.
00:38:36.600 --> 00:38:39.703 Uh check is this by ID with an invalid ID should throw an
00:38:39.703 --> 00:38:43.180 invalid operation exception and that's the name of our test that
00:38:43.180 --> 00:38:44.090 we throw in here.
00:38:45.050 --> 00:38:47.731 What we do with this one is the arrangement is slightly
00:38:47.731 --> 00:38:48.210 different.
00:38:48.980 --> 00:38:53.448 Umm, part of the we since we are expecting it to throw part of
00:38:53.448 --> 00:38:57.704 the arrangement is that we operate those things against the
00:38:57.704 --> 00:39:00.470 action and we assert at the same time.
00:39:00.630 --> 00:39:03.323 So really this part is a little bit of a misnomer, so I'll take
00:39:03.323 --> 00:39:04.460 this and move this up here.
00:39:04.580 --> 00:39:08.152 And so that we're arranging up to there and then we'll say that
00:39:08.152 --> 00:39:11.836 we are both acting and asserting at the same time because we have
00:39:11.836 --> 00:39:15.408 to do them at the same time in order to make this call where it
00:39:15.408 --> 00:39:16.190 does the same.
00:39:16.200 --> 00:39:19.775 We don't do a Tri catch, we do an assert that it throws an
00:39:19.775 --> 00:39:23.652 exception of a particular type and then inside of it we have it
00:39:23.652 --> 00:39:27.166 an action here that's basically like a task to physically
00:39:27.166 --> 00:39:30.620 execute that option at have it do what it's going to do.
00:39:30.860 --> 00:39:33.652 So when we assert this, we are saying that it's supposed to
00:39:33.652 --> 00:39:36.537 come back with this particular thing and see that since we're
00:39:36.537 --> 00:39:37.980 passing A00, is not a valid ID.
00:39:38.020 --> 00:39:39.150 So why would you ever do that?
00:39:39.160 --> 00:39:39.770 How dare you?
00:39:39.860 --> 00:39:42.037 So let's make sure that our negative path throws an
00:39:42.037 --> 00:39:44.548 exception when when it when it does it, and so this is what
00:39:44.548 --> 00:39:45.260 it's going to do.
00:39:45.310 --> 00:39:48.097 And you'll notice here that we do the simplified tests where
00:39:48.097 --> 00:39:50.838 it's just checking this table because we don't need to load
00:39:50.838 --> 00:39:53.580 all of this other data in order to test this negative path.
00:39:53.630 --> 00:39:55.491 So that's why we have two different ones here that do that
00:39:55.491 --> 00:39:55.680 stuff.
00:39:55.690 --> 00:39:58.788 We have one that's really simplified and we have the more
00:39:58.788 --> 00:40:02.154 advanced one that does all of this extra data and it lets this
00:40:02.154 --> 00:40:04.878 task, this test run faster because it's physically
00:40:04.878 --> 00:40:08.404 operating all those other tables into memory on our fake database
00:40:08.404 --> 00:40:10.060 that lets us do all that stuff.
00:40:10.070 --> 00:40:12.940 Nice and Clint can cleanly, and I'll put that back there we go.
00:40:14.290 --> 00:40:17.442 So that's a negative path where you can test this is coming into
00:40:17.442 --> 00:40:20.158 here and doing that kind of stuff as you assert that it
00:40:20.158 --> 00:40:23.067 throws another negative path might be that it's returning a
00:40:23.067 --> 00:40:24.910 failing Seth AR Seth action response.
00:40:24.960 --> 00:40:29.760 Something you find one of those and do a failing.
00:40:31.000 --> 00:40:33.900 OK, verify Sefa are failed with single message message.
00:40:35.130 --> 00:40:37.320 So this one is kind of a misnomer and says that it's
00:40:37.320 --> 00:40:37.940 returning null.
00:40:38.330 --> 00:40:42.002 Really it's returning a failing stuff AR, so I should probably
00:40:42.002 --> 00:40:45.500 rename that task test and fix it, but I'll do that later in
00:40:45.500 --> 00:40:47.540 deal with it in its own good time.
00:40:47.770 --> 00:40:51.820 So here we're doing a let's do a range.
00:40:54.100 --> 00:40:57.720 Let's do this is our act, and then this is our research.
00:40:58.750 --> 00:41:00.350 We're not doing it at the same time.
00:41:00.490 --> 00:41:01.350 I can get rid of that part.
00:41:03.880 --> 00:41:06.800 And then again, we have our creating a container for memory.
00:41:06.810 --> 00:41:08.832 We're passing the context profile name through the
00:41:08.832 --> 00:41:11.210 functions that were operating, and then we expected to come
00:41:11.210 --> 00:41:12.400 back with a particular result.
00:41:12.520 --> 00:41:14.987 Now you'll notice here this is a negative path that we're
00:41:14.987 --> 00:41:15.370 checking.
00:41:15.490 --> 00:41:19.003 We basically passed no valid data into this resolve with
00:41:19.003 --> 00:41:21.160 autogenerated optional thing here.
00:41:21.670 --> 00:41:25.147 So when I go look at that function on the T workflow and I
00:41:25.147 --> 00:41:28.270 go find it, it's probably gonna be in workflow base.
00:41:29.640 --> 00:41:34.110 What it does is it asks the context or asks the retry
00:41:34.110 --> 00:41:34.690 loader.
00:41:34.700 --> 00:41:38.325 Our DI system, which is structure map internally for the
00:41:38.325 --> 00:41:42.331 container that has that name to give me a context which is the
00:41:42.331 --> 00:41:46.210 Clarity Conference entities which has been mocked in memory.
00:41:46.680 --> 00:41:49.404 It's going to ask for that context with this disposable,
00:41:49.404 --> 00:41:52.320 and then we'll go through and and operate this one, which is
00:41:52.320 --> 00:41:55.188 right below it, which just passes in the context to it, and
00:41:55.188 --> 00:41:57.961 then also if it needed to, it could take context, context
00:41:57.961 --> 00:41:58.630 profile, name.
00:41:58.640 --> 00:42:02.203 It could pull the context back off of it in case whatever the
00:42:02.203 --> 00:42:05.708 thing I'm doing, it needs to pass it in, but I can pass this
00:42:05.708 --> 00:42:07.030 context around as well.
00:42:07.040 --> 00:42:09.660 There's already been pulled out for operating in memory.
00:42:09.850 --> 00:42:13.908 It's gonna pass that stuff down as the context to like resolve
00:42:13.908 --> 00:42:16.420 async and to this await and get calls.
00:42:16.430 --> 00:42:19.985 All this other stuff and like create it if it's not there, but
00:42:19.985 --> 00:42:23.146 people always talk to the context that I have asked for
00:42:23.146 --> 00:42:26.363 because I'm passing in this context profile name of that
00:42:26.363 --> 00:42:29.806 particular name and it won't step on some other tests that's
00:42:29.806 --> 00:42:33.305 going its own thing and might have at the same time in memory
00:42:33.305 --> 00:42:36.522 of the app domain written its own context profiling with
00:42:36.522 --> 00:42:38.610 different information on that stuff.
00:42:38.620 --> 00:42:41.907 It's we silo all that stuff all the way through and then live
00:42:41.907 --> 00:42:43.550 production is always just null.
00:42:43.680 --> 00:42:46.712 It doesn't specify one, it just runs everything with null and
00:42:46.712 --> 00:42:49.549 then gets the actual live information that way so that we
00:42:49.549 --> 00:42:52.630 prevent us from having to deal with anything weird or special.
00:42:55.130 --> 00:42:57.985 So we come through and it clears that stuff up and you know,
00:42:57.985 --> 00:43:01.027 comes back here with our failing stuff are we're expecting it to
00:43:01.027 --> 00:43:04.023 kind of basically come through with the unable to generate with
00:43:04.023 --> 00:43:05.240 the automated information.
00:43:05.750 --> 00:43:08.389 If this was a not optional one, if it was the main one, we
00:43:08.389 --> 00:43:11.118 expect that one to throw an exception, so we handle that one
00:43:11.118 --> 00:43:13.220 differently than this one where it's optional.
00:43:13.230 --> 00:43:16.942 So it's allowed to return a null or a failing stuff air instead
00:43:16.942 --> 00:43:18.740 of blowing up what we're doing.
00:43:19.040 --> 00:43:25.564 An example of that might be you are relating a record that has a
00:43:25.564 --> 00:43:29.980 type but is not required to have that type.
00:43:29.990 --> 00:43:34.485 If it just it's optional for that one, why is my hand up take
00:43:34.485 --> 00:43:36.660 my hand down stupid thing, OK?
00:43:37.450 --> 00:43:38.370 Uh.
00:43:38.490 --> 00:43:39.760 And operate that stuff backwards.
00:43:39.810 --> 00:43:43.180 OK, so I come back over to where our test is.
00:43:43.810 --> 00:43:46.406 We get our our value back and then we assert using our
00:43:46.406 --> 00:43:49.285 convenience method here that says that it's supposed to have
00:43:49.285 --> 00:43:50.560 failed with single message.
00:43:50.570 --> 00:43:52.872 So it will go through and then some having to rewrite these
00:43:52.872 --> 00:43:54.100 same things over and over again.
00:43:54.110 --> 00:43:56.978 I put them into this common function that can operate and
00:43:56.978 --> 00:44:00.044 expect it to come back with a particular message and all that
00:44:00.044 --> 00:44:02.270 stuff is nice and neat and kept kept simple.
00:44:03.170 --> 00:44:08.493 On here, we're checking all kinds of different stuff that we
00:44:08.493 --> 00:44:11.810 have code coverage of our main flows.
00:44:11.940 --> 00:44:15.350 So if I come into the account section here, I'm going to go
00:44:15.350 --> 00:44:17.510 ahead and do the accounts themselves.
00:44:18.650 --> 00:44:22.520 Whoops, where is my account section?
00:44:23.290 --> 00:44:25.560 Ohh that's why cause I collapsed that main part.
00:44:26.710 --> 00:44:29.459 There's our main accounts standard workflow test here, so
00:44:29.459 --> 00:44:32.207 these are our main 11 for accounts cause now accounts are
00:44:32.207 --> 00:44:34.340 basically have the name able checks on them.
00:44:34.490 --> 00:44:36.698 I'll make this part a bit bigger so that you guys can see it
00:44:36.698 --> 00:44:38.942 better and I will physically not just run them, but I want to
00:44:38.942 --> 00:44:39.340 cover them.
00:44:40.900 --> 00:44:41.490 Oh, wait.
00:44:42.060 --> 00:44:42.610 Oh, there you go.
00:44:42.660 --> 00:44:45.542 I analyze code coverage which will execute the test and
00:44:45.542 --> 00:44:48.476 include additional stuff which will make it makes it run
00:44:48.476 --> 00:44:51.719 slower, but that code coverage tells me that we have covered a
00:44:51.719 --> 00:44:54.704 bunch of positive and or negative pads in what it's doing
00:44:54.704 --> 00:44:57.690 and I'll get syntax highlighting on some of these things.
00:44:57.700 --> 00:45:00.885 Whenever that does that, however, the Resharper wins much
00:45:00.885 --> 00:45:01.270 better.
00:45:01.320 --> 00:45:04.795 So again, I don't really do it very often here with the and the
00:45:04.795 --> 00:45:06.750 built in Visual Studio test runner.
00:45:06.990 --> 00:45:09.070 I'll run it again with the three sharper ones.
00:45:09.080 --> 00:45:09.720 We see the difference.
00:45:11.000 --> 00:45:14.927 Excuse me, but the code coverage will result tell me that whether
00:45:14.927 --> 00:45:18.617 or not I'm actually covering all of my different scenarios of
00:45:18.617 --> 00:45:22.069 stuff that I've not only written, but I've overridden umm
00:45:22.069 --> 00:45:24.330 from the T fours to do custom things.
00:45:24.520 --> 00:45:26.883 I need to make sure that all of this stuff is covered as best as
00:45:26.883 --> 00:45:27.210 possible.
00:45:27.910 --> 00:45:30.330 100% coverage is not something we're ever gonna look for.
00:45:30.340 --> 00:45:33.418 It's got diminishing returns when you get to that point, so
00:45:33.418 --> 00:45:36.702 we don't mess with that, but we do want to get a good 70 to 80%
00:45:36.702 --> 00:45:40.037 coverage because that will most likely cover all of the positive
00:45:40.037 --> 00:45:43.218 paths and at least some of the negative ads are gonna be more
00:45:43.218 --> 00:45:44.090 common for stuff.
00:45:44.700 --> 00:45:47.021 And ideally, if you're running in a new path, has caused
00:45:47.021 --> 00:45:49.669 creates new logic branch, you've written some kind of tests that
00:45:49.669 --> 00:45:50.850 we will go and exercise that.
00:45:51.250 --> 00:45:53.560 But in reality, that's not happening.
00:45:53.610 --> 00:45:55.888 So I'm not gonna shoot you in the foot because you didn't do
00:45:55.888 --> 00:45:56.000 it.
00:45:57.180 --> 00:45:59.074 If you guys get into the practice of doing that, that
00:45:59.074 --> 00:45:59.670 would be amazing.
00:45:59.740 --> 00:46:00.730 I home.
00:46:00.780 --> 00:46:04.000 I'm holding my breath on whether that actually happens.
00:46:06.260 --> 00:46:09.504 So right now it's executing it with the analyze code coverage
00:46:09.504 --> 00:46:09.870 set on.
00:46:10.420 --> 00:46:13.952 It's doing a random test out of the group and and it's going to
00:46:13.952 --> 00:46:16.050 spit through and see what it's doing.
00:46:17.980 --> 00:46:18.410 Yep.
00:46:18.420 --> 00:46:20.990 So these are passing and it's gonna give us code coverage.
00:46:21.850 --> 00:46:24.230 I don't know how this one in in built in code coverage.
00:46:24.240 --> 00:46:27.038 Tool actually looks, so we're about to find out together what
00:46:27.038 --> 00:46:27.670 it looks like.
00:46:32.550 --> 00:46:35.352 So you see here like a lot of them took like 1.4 or whatever
00:46:35.352 --> 00:46:35.720 seconds.
00:46:36.730 --> 00:46:39.143 That's because the code coverage makes the test run slower
00:46:39.143 --> 00:46:41.310 because it has to actually analyze more information.
00:46:41.320 --> 00:46:43.420 It's like doing a profiling of it at the same time.
00:46:43.550 --> 00:46:45.891 It's not the performance of the test, but it's about like what
00:46:45.891 --> 00:46:46.560 code branches did.
00:46:46.570 --> 00:46:49.872 It touched as it did it so as it came through, we can now see
00:46:49.872 --> 00:46:53.175 that there are covered blocks in a lot of different areas and
00:46:53.175 --> 00:46:56.371 I'll sort by like the the most covered blocks to the to the
00:46:56.371 --> 00:46:57.490 least covered blocks.
00:46:58.050 --> 00:47:00.370 And there's a lot of stuff that's covered in testing there.
00:47:00.380 --> 00:47:03.360 Holy crap, how did it cover all that stuff?
00:47:03.870 --> 00:47:04.360 I don't know.
00:47:04.370 --> 00:47:05.040 That's crazy.
00:47:05.990 --> 00:47:07.340 I don't trust that at all.
00:47:07.870 --> 00:47:08.440 For what?
00:47:08.450 --> 00:47:13.589 It just did and then not cover blocks and covered lines like
00:47:13.589 --> 00:47:18.560 let's go into say, the workflow workflow account workflow.
00:47:18.570 --> 00:47:25.490 It covered 101 blocks, 37 lines, and it did it.
00:47:26.130 --> 00:47:29.430 If I double click it, it doesn't go to the code.
00:47:29.440 --> 00:47:34.204 If I double click here it does OK, so we have some code
00:47:34.204 --> 00:47:34.970 coverage.
00:47:34.980 --> 00:47:38.258 I think that's what that light blue is telling me is that
00:47:38.258 --> 00:47:38.880 discovered.
00:47:38.890 --> 00:47:42.172 Yeah, covered lines is the light blue in the background, so it's
00:47:42.172 --> 00:47:45.050 really hard to see with the coverage that they provided.
00:47:45.800 --> 00:47:49.411 I think I can actually say remove and it will remove the OR
00:47:49.411 --> 00:47:52.360 like dump the coverage block and clear that out.
00:47:52.480 --> 00:47:54.763 I think the receiver one is better, but it's basically
00:47:54.763 --> 00:47:57.170 saying it covered certain blocks and didn't cover others.
00:47:57.750 --> 00:48:01.525 Umm, the partially covered, so like it didn't it didn't
00:48:01.525 --> 00:48:05.704 exercise anything inside this this where statement but it did
00:48:05.704 --> 00:48:09.883 exercise the outside of a part where the other stuff went and
00:48:09.883 --> 00:48:12.310 it did exercise some stuff in here.
00:48:12.460 --> 00:48:15.961 So I guess it wasn't a pattern that it had to deal with or that
00:48:15.961 --> 00:48:18.040 was nullable in the test that it ran.
00:48:19.420 --> 00:48:19.970 Who knows?
00:48:20.170 --> 00:48:23.189 But when you have these numbers here together, what you end up
00:48:23.189 --> 00:48:26.160 with is the ability to look for percentages of code coverage.
00:48:26.750 --> 00:48:28.820 Now obviously this is not including percentages.
00:48:28.830 --> 00:48:32.060 Maybe there's columns I can add that will tell me percentages.
00:48:32.070 --> 00:48:33.130 Yeah, here we go, percentages.
00:48:35.430 --> 00:48:37.260 So let's add some of those and see what it says.
00:48:37.830 --> 00:48:43.687 OK, so like let's say out of workflows DLL 97% almost 98% is
00:48:43.687 --> 00:48:46.760 not covered and 1.5% is covered.
00:48:48.290 --> 00:48:50.861 So that's a lot that's not covered because we only covered
00:48:50.861 --> 00:48:51.820 this one set of steps.
00:48:51.830 --> 00:48:55.504 If I were to run all of them, it would take a little while for it
00:48:55.504 --> 00:48:59.011 to go through all of them, but then it would probably come out
00:48:59.011 --> 00:49:02.185 something about 2930% code coverage because we're mostly
00:49:02.185 --> 00:49:04.690 only covering what's run by force right now.
00:49:05.820 --> 00:49:07.708 That's kind of like what it's what it's doing with those
00:49:07.708 --> 00:49:07.940 things.
00:49:09.140 --> 00:49:11.880 If I drop these results, I'm going to drop his code coverage.
00:49:13.730 --> 00:49:16.704 I'm going to say OK and then I'll close that window cause I
00:49:16.704 --> 00:49:17.250 don't care.
00:49:17.540 --> 00:49:19.700 I'm gonna open the Visual Studio.
00:49:19.710 --> 00:49:21.430 I'm sorry the Resharper 1 instead.
00:49:21.720 --> 00:49:24.780 This is the Resharper test explorer which doesn't execute.
00:49:24.790 --> 00:49:26.390 Test it just makes you can make a session.
00:49:26.520 --> 00:49:30.176 So if I write click, click this and say create new session, it
00:49:30.176 --> 00:49:33.658 opens the unit test sessions window which I'm gonna make it
00:49:33.658 --> 00:49:36.850 bigger here so you guys can really see what it can do.
00:49:38.020 --> 00:49:40.340 Umm, we had those.
00:49:40.350 --> 00:49:44.025 If I go find the same tests, let's go down to workflows,
00:49:44.025 --> 00:49:45.250 accounts, accounts.
00:49:47.070 --> 00:49:50.182 Here are the account, and here's the same 11 and I right click
00:49:50.182 --> 00:49:51.170 and say cover tests.
00:49:54.370 --> 00:49:55.570 This is what this one going to do.
00:49:55.580 --> 00:49:57.010 I get my code coverage window to pop up.
00:49:59.980 --> 00:50:02.220 And it tells me I have all target frameworks.
00:50:02.230 --> 00:50:05.974 I really only care about NET Framework 472, so like to know
00:50:05.974 --> 00:50:07.410 the other one branches.
00:50:08.570 --> 00:50:12.258 It's covering those tests, and then it's gonna tell me coverage
00:50:12.258 --> 00:50:13.930 statements about those tests.
00:50:16.790 --> 00:50:17.450 When they finish.
00:50:23.100 --> 00:50:24.510 All these wonderful things are running.
00:50:25.510 --> 00:50:29.116 We know they're going to pass because we just ran him over
00:50:29.116 --> 00:50:32.600 here, but we get our code coverage block in here and now
00:50:32.600 --> 00:50:35.350 we have 5% of the total solution is covered.
00:50:36.740 --> 00:50:40.381 Of what's covered, the biggest block that got covered was the
00:50:40.381 --> 00:50:44.082 models of mapping layer at 13% because it was able to exercise
00:50:44.082 --> 00:50:46.490 a bunch of mapping stuff which was cool.
00:50:46.700 --> 00:50:49.299 So if I Scroll down through this, let's see what the most
00:50:49.299 --> 00:50:50.420 covered mapping part got.
00:50:50.430 --> 00:50:53.880 Gun the base model Mapper got this stuff, which is a nice
00:50:53.880 --> 00:50:55.010 bright green color.
00:50:55.020 --> 00:50:57.318 It means these both covered and it was a passing test that was
00:50:57.318 --> 00:50:57.610 covered.
00:50:57.620 --> 00:51:00.683 If it was a failing test, it would make it a bright red or
00:51:00.683 --> 00:51:03.903 kind of print pinkish color on this stuff, and I can see that
00:51:03.903 --> 00:51:04.370 exercise.
00:51:04.380 --> 00:51:07.672 All of this stuff and that it was happy, but this Gray block
00:51:07.672 --> 00:51:11.180 here was an area that it didn't cover, so I might want to go add
00:51:11.180 --> 00:51:14.527 a test that would physically exercise this block because it's
00:51:14.527 --> 00:51:16.470 not been covered correctly and now.
00:51:16.480 --> 00:51:19.884 And by doing that, it would cover more of this thing and get
00:51:19.884 --> 00:51:21.280 82% even higher on there.
00:51:23.040 --> 00:51:25.782 So there's account card workflow got covered, it ran and did that
00:51:25.782 --> 00:51:25.990 part.
00:51:26.620 --> 00:51:29.670 If I expand it out, I can see the individual blocks that got
00:51:29.670 --> 00:51:30.070 covered.
00:51:30.240 --> 00:51:32.593 If I go look at this one like this one got 100% covered
00:51:32.593 --> 00:51:35.157 because there was only three things inside it and it did all
00:51:35.157 --> 00:51:36.040 of them successfully.
00:51:36.750 --> 00:51:40.686 Umm, if I were to do more tests and add on to this, I'm betting
00:51:40.686 --> 00:51:44.377 I could make it run do more stuff, but my audio might break
00:51:44.377 --> 00:51:46.960 up a little bit, so I'm just going to do.
00:51:47.670 --> 00:51:51.131 I'm going to cover a few of these guys here in different
00:51:51.131 --> 00:51:53.500 sections rather than just one section.
00:51:53.950 --> 00:51:57.409 You'll notice that because I'm telling it to cover, it does not
00:51:57.409 --> 00:51:58.760 run in them side by side.
00:51:58.770 --> 00:52:01.410 It only runs one at a time.
00:52:02.130 --> 00:52:03.120 Uh in their stuff.
00:52:03.130 --> 00:52:06.693 If you do a regular run of it, and that's not code coverage,
00:52:06.693 --> 00:52:09.030 run, it should run tests from each one.
00:52:09.540 --> 00:52:12.760 Uh side by side on this stuff.
00:52:12.770 --> 00:52:14.698 It looks like actually maybe maybe I'm wrong, maybe they
00:52:14.698 --> 00:52:15.070 changed it.
00:52:16.660 --> 00:52:19.312 Yeah, it's allowing it to run each domain one from each domain
00:52:19.312 --> 00:52:20.660 at the same time, which is nice.
00:52:21.570 --> 00:52:22.330 They didn't used to do that.
00:52:25.520 --> 00:52:26.050 Azar.
00:52:26.600 --> 00:52:27.060 New changes.
00:52:29.240 --> 00:52:32.136 Fancy things and as each one of these actually completes, it
00:52:32.136 --> 00:52:34.795 does update the coverage snapshot, adding more and more
00:52:34.795 --> 00:52:35.080 to it.
00:52:35.960 --> 00:52:38.819 Umm, but of course, as I'm doing it, it's, you know, eating a
00:52:38.819 --> 00:52:41.817 bunch of my CPU, so it's kind of slowing down and speeding up as
00:52:41.817 --> 00:52:42.970 it as it does this stuff.
00:52:45.880 --> 00:52:46.320 I'll collapse.
00:52:46.330 --> 00:52:50.131 We're already up to 16%, OK, so it finished and ran all those,
00:52:50.131 --> 00:52:53.450 you know, pretty quickly, about 20 to 30 seconds each.
00:52:54.180 --> 00:52:56.661 But it was able to do a bunch of at the same time, so it kind of
00:52:56.661 --> 00:52:57.730 overlapped all those things.
00:52:57.740 --> 00:53:01.185 If I were to come in and do more stuff, like let's close little
00:53:01.185 --> 00:53:04.308 cover like orders, I said I start typing order and then I
00:53:04.308 --> 00:53:07.753 can see everything that comes up with under that I can collapse
00:53:07.753 --> 00:53:08.130 it all.
00:53:08.140 --> 00:53:09.410 So I can just look at the headers here.
00:53:09.620 --> 00:53:11.050 Like, here's all the ordering section.
00:53:11.300 --> 00:53:13.782 If I cover those tests specifically, I know it will
00:53:13.782 --> 00:53:16.265 cover some extra stuff because the orders are sales
00:53:16.265 --> 00:53:19.368 collections, so there's a lot of shared code around that kind of
00:53:19.368 --> 00:53:22.423 thing that we'll get covered by those that running the purchase
00:53:22.423 --> 00:53:22.710 order.
00:53:22.720 --> 00:53:26.069 One wouldn't be redundant a little bit for those shared
00:53:26.069 --> 00:53:28.640 portions because they're shared for stuff.
00:53:30.070 --> 00:53:32.380 Well, I'll go ahead and get a little bit of that covered.
00:53:33.350 --> 00:53:36.257 I would never recommend on your local like telling you to just
00:53:36.257 --> 00:53:39.026 run all tests at once, because it gets kind of confused and
00:53:39.026 --> 00:53:41.380 bogged down even at this level of number of tests.
00:53:42.110 --> 00:53:44.860 So I would say like maybe do like 1/4 of them at a time.
00:53:45.590 --> 00:53:49.754 If you're going to queue them up, umm, so I would go to see
00:53:49.754 --> 00:53:54.195 where it's 17% now and let's see if how much further when these
00:53:54.195 --> 00:53:55.930 guys finish sales orders.
00:53:55.940 --> 00:53:56.700 One is the big one.
00:53:59.260 --> 00:54:00.210 It's taking a while.
00:54:02.240 --> 00:54:03.110 Because it's a big one.
00:54:10.960 --> 00:54:11.580 Dude.
00:54:11.590 --> 00:54:12.160 Dude.
00:54:12.170 --> 00:54:13.450 Dude, dude, dude.
00:54:13.460 --> 00:54:15.420 Something took 46 seconds and it might have started.
00:54:15.430 --> 00:54:17.850 It started later as well and we're up to 18% coverage.
00:54:18.100 --> 00:54:21.064 So if I were to look at this entire like scroll bar here of
00:54:21.064 --> 00:54:23.930 stuff, I would probably go do everything that was not the
00:54:23.930 --> 00:54:25.610 workflows ones except C database.
00:54:25.620 --> 00:54:29.167 I'll take those out and I would tell it to cover those that I
00:54:29.167 --> 00:54:29.510 could.
00:54:29.640 --> 00:54:33.180 I know that they're all done and out of the way, but for all the
00:54:33.180 --> 00:54:36.284 providers and data model and mapping layer that's that's
00:54:36.284 --> 00:54:38.790 lower specifically exercising certain things.
00:54:43.060 --> 00:54:45.469 And you'll see a bunch of these are just automatically ignored,
00:54:45.469 --> 00:54:46.900 so it doesn't even do anything there.
00:54:46.910 --> 00:54:49.270 So the little eye with the line through meaning it was ignored.
00:54:50.140 --> 00:54:51.340 It's not looking at the results.
00:54:55.200 --> 00:54:58.549 And then it doesn't even run them in the 1st place and we
00:54:58.549 --> 00:55:00.050 have 31 skipped right now.
00:55:00.500 --> 00:55:01.920 I'll let it finish doing what it's doing.
00:55:04.690 --> 00:55:07.844 So what I normally do when I come in here and I'm like trying
00:55:07.844 --> 00:55:10.997 to exercise the new stuff is I will go through and I'll click
00:55:10.997 --> 00:55:13.693 on the tests that haven't been run or don't have any
00:55:13.693 --> 00:55:16.440 information, and then I'll control click on this guy.
00:55:16.450 --> 00:55:19.894 So I see the failed tests too, and then as I run the tests,
00:55:19.894 --> 00:55:20.640 they're good.
00:55:20.650 --> 00:55:21.600 They get out of my view.
00:55:21.610 --> 00:55:22.450 I have to look at it anymore.
00:55:23.540 --> 00:55:26.921 If they're covered and I changed something that affects the code
00:55:26.921 --> 00:55:30.198 coverage that the test covered, it will put them back into the
00:55:30.198 --> 00:55:33.371 unknown state so that I could see them again and that I need
00:55:33.371 --> 00:55:34.880 to rerun them, which is nice.
00:55:36.450 --> 00:55:38.711 That's one of the advantages of covering tests rather than just
00:55:38.711 --> 00:55:39.170 running them.
00:55:41.660 --> 00:55:43.010 Sometimes he kind of figured that out.
00:55:43.020 --> 00:55:45.881 If you modify the test itself, but it like code that it was
00:55:45.881 --> 00:55:49.027 dependent on, that's down in the lower layers of workflow or data
00:55:49.027 --> 00:55:51.030 model or mapping that might have changed.
00:55:51.040 --> 00:55:53.330 It doesn't necessarily know that that test coverage has been
00:55:53.330 --> 00:55:53.630 updated.
00:55:53.640 --> 00:55:57.159 If you don't have coverage and run it with coverage so it
00:55:57.159 --> 00:56:00.799 doesn't tell you that it needs to be that it's dirty, quote
00:56:00.799 --> 00:56:04.743 unquote and it needs to go back, I can see here that the caching
00:56:04.743 --> 00:56:08.444 failed and that's I know why, because the linked to Redis is
00:56:08.444 --> 00:56:12.449 bad in the default file for what I my local setup is because I am
00:56:12.449 --> 00:56:14.330 not using my local host for it.
00:56:14.340 --> 00:56:15.520 I'm using what is inside.
00:56:18.660 --> 00:56:20.600 The server in Ben's house.
00:56:24.970 --> 00:56:25.780 And I'm going to.
00:56:27.040 --> 00:56:28.770 I don't even have the retest values in here.
00:56:28.780 --> 00:56:31.950 I have my other one and I can get back here.
00:56:32.210 --> 00:56:32.870 Get back up there.
00:56:34.030 --> 00:56:34.390 Get over.
00:56:34.400 --> 00:56:40.213 Here you go over to my 2020 at two and my testing and my main
00:56:40.213 --> 00:56:46.308 testing and I look at this file and I should be able to copy the
00:56:46.308 --> 00:56:48.090 values I need here.
00:56:49.600 --> 00:56:49.830 Yeah.
00:56:49.840 --> 00:56:50.130 There we go.
00:56:51.290 --> 00:56:56.030 This is Redis and there's two are the elastic search changes.
00:56:59.690 --> 00:57:04.130 Those and then I want to put them down into both.
00:57:06.610 --> 00:57:07.080 There we go.
00:57:07.090 --> 00:57:10.980 This is where I had it before, so I will put them there and
00:57:10.980 --> 00:57:14.741 then I'm going to nuke those original lines so that I can
00:57:14.741 --> 00:57:18.891 talk to the correct IP address on this and then I'll just close
00:57:18.891 --> 00:57:19.540 this file.
00:57:20.110 --> 00:57:23.790 And then once these are done, I'm going to return them.
00:57:23.800 --> 00:57:26.699 Actually, I probably should have to kill it right now, so I hit
00:57:26.699 --> 00:57:29.462 stop and then I hit the hand stop which tells it to forcibly
00:57:29.462 --> 00:57:29.960 execute it.
00:57:30.290 --> 00:57:33.100 Or I'm I'm forcibly kill it and it will do that until it can.
00:57:33.370 --> 00:57:35.644 Then it will come back and reselect these and then I'll
00:57:35.644 --> 00:57:36.660 tell them to cover again.
00:57:36.970 --> 00:57:40.721 Now that the the setting has changed, so they could probably
00:57:40.721 --> 00:57:43.980 pass once and talk by talking to the correct server.
00:57:48.220 --> 00:57:49.830 And sometimes things just hit up.
00:57:50.360 --> 00:57:53.405 We're like it was talking to Ritas and Ritas crapped out and
00:57:53.405 --> 00:57:56.100 didn't want to give a good value to get a bad return.
00:57:57.890 --> 00:58:02.349 We have protection within the PR analyzer runners so that it must
00:58:02.349 --> 00:58:06.336 fail the same way three times before it will actually fail
00:58:06.336 --> 00:58:08.160 your PR for a failing test.
00:58:08.510 --> 00:58:09.940 Because of those kinds of hiccups.
00:58:10.550 --> 00:58:11.860 So there is protection in there.
00:58:11.910 --> 00:58:15.540 So if you saw that happen, don't freak out.
00:58:15.550 --> 00:58:18.506 Go in and look at the actual failures inside the build and
00:58:18.506 --> 00:58:21.714 see where it actually failed and if it actually failed that way
00:58:21.714 --> 00:58:24.921 three times before it did that and you can see now it passed it
00:58:24.921 --> 00:58:28.178 and moved it onto the past color over there instead of giving me
00:58:28.178 --> 00:58:28.880 errors for it.
00:58:31.760 --> 00:58:33.470 Sweet and it's down to just a few tests.
00:58:35.210 --> 00:58:40.910 Uh oh, I think I when I hit cancel it's put more stuff in.
00:58:40.920 --> 00:58:43.302 Ignored that I need to because it had inconsistent results
00:58:43.302 --> 00:58:44.150 because I stopped it.
00:58:44.920 --> 00:58:49.510 Whatever it was, I can tell it to cleanly do this again.
00:58:49.520 --> 00:58:51.967 That way it updates and refreshes those and the ones
00:58:51.967 --> 00:58:54.230 that need to run will run everyone's that don't.
00:58:54.240 --> 00:58:55.540 We'll just go back into ignored.
00:58:59.190 --> 00:59:01.528 OK, kind of covering the stuff in like, dumb and weird ways a
00:59:01.528 --> 00:59:03.829 little bit, just so that you guys can see it happen and what
00:59:03.829 --> 00:59:04.810 to do when it does happen.
00:59:06.540 --> 00:59:07.690 See, there's only 9 right now.
00:59:08.660 --> 00:59:12.127 Discounts has a lot of testing and they're slow because of all
00:59:12.127 --> 00:59:15.430 the different things they have to do, so they take a while.
00:59:18.860 --> 00:59:19.490 Dude.
00:59:19.500 --> 00:59:20.080 Dude.
00:59:20.140 --> 00:59:20.510 Dude.
00:59:20.600 --> 00:59:21.980 Dude, dude. Dude.
00:59:31.670 --> 00:59:34.592 When the other things you can get from your code coverage by
00:59:34.592 --> 00:59:37.371 operating the stuff you see here, then we're up to 12% on
00:59:37.371 --> 00:59:40.294 the whole thing is hot spots by clicking on hotspots it will
00:59:40.294 --> 00:59:42.977 show you code that is not currently covered and has the
00:59:42.977 --> 00:59:43.600 highest risk.
00:59:43.610 --> 00:59:46.100 Messaging because it's the most complex class.
00:59:46.530 --> 00:59:48.540 For instance, this is FedEx extensions.
00:59:48.810 --> 00:59:52.179 It has some huge thing in here that is a giant switch case that
00:59:52.179 --> 00:59:55.444 returns a bunch of different stuff, and because this thing is
00:59:55.444 --> 00:59:58.550 so huge and there's nothing exercising it, it's calling it
00:59:58.550 --> 01:00:01.709 out as a giant red flag that something needs to come in and
01:00:01.709 --> 01:00:02.130 do this.
01:00:02.940 --> 01:00:07.190 Now you know, I know this is a really dumb simple switch case.
01:00:07.550 --> 01:00:10.480 There's not a whole lot here to really worry about.
01:00:11.680 --> 01:00:15.500 It's just checking one text and converting it to another value,
01:00:15.500 --> 01:00:19.141 and honestly most of this could actually just be data in our
01:00:19.141 --> 01:00:22.783 database if there were country stuff, so I'm not too worried
01:00:22.783 --> 01:00:23.320 about it.
01:00:23.330 --> 01:00:26.764 I could tell it to exclude it from the coverage, or I could
01:00:26.764 --> 01:00:30.370 just try to make a dummy test that literally just exercises it
01:00:30.370 --> 01:00:33.919 like loops through all these strings and and does that really
01:00:33.919 --> 01:00:37.525 quickly so I could do that and then that would be take care of
01:00:37.525 --> 01:00:40.960 this thing that has a rich semantic of 446,892 because it's
01:00:40.960 --> 01:00:42.620 cyclomatic complexity is 668.
01:00:44.570 --> 01:00:47.127 From all the different branches of of, you know, logical
01:00:47.127 --> 01:00:49.460 branches of code that I can follow through in here.
01:00:49.980 --> 01:00:52.796 And then we show me like the next highest one, which is gonna
01:00:52.796 --> 01:00:55.295 be like the target order checkout provider, which is a
01:00:55.295 --> 01:00:56.340 risk measure of 32,220.
01:00:56.470 --> 01:00:59.980 Note how the disparity between the top one and the next highest
01:00:59.980 --> 01:01:01.900 one is so huge on its risk metric.
01:01:02.850 --> 01:01:05.255 If I click on this, it goes to the next highest thing and it
01:01:05.255 --> 01:01:07.700 says the analyze inner is the most complicated thing in here.
01:01:08.710 --> 01:01:11.779 Well, yeah, I know it is really bad because it is doing so much
01:01:11.779 --> 01:01:14.705 stuff in here and it can be confusing and hard to work with,
01:01:14.705 --> 01:01:17.871 but I actually do have some test coverage on this, I just haven't
01:01:17.871 --> 01:01:18.830 run those tests yet.
01:01:19.620 --> 01:01:22.335 Umm in here, so I will come back and deal with those at some
01:01:22.335 --> 01:01:24.160 point, then remove the CC database ones.
01:01:24.170 --> 01:01:27.894 They don't matter and everything that's still under the ignored
01:01:27.894 --> 01:01:31.270 part here, I don't need to keep messing with these tests.
01:01:31.280 --> 01:01:34.970 I'm gonna physically remove them from my session because I don't.
01:01:34.980 --> 01:01:36.190 I don't ever need to run them again.
01:01:36.200 --> 01:01:39.325 I don't need them to even try to run again, so I'll go take them
01:01:39.325 --> 01:01:39.710 all out.
01:01:46.300 --> 01:01:48.480 That is all of those tests removed.
01:01:49.340 --> 01:01:50.430 Now the parents still there.
01:01:50.440 --> 01:01:53.589 There may be other stuff that's underneath those tests sections,
01:01:53.589 --> 01:01:56.690 but I don't have them in here, so I'm gonna go ahead and do so.
01:01:56.700 --> 01:01:59.230 OK, so this is what's left is we have this bar going through all
01:01:59.230 --> 01:02:01.565 of this different stuff is basically just all the different
01:02:01.565 --> 01:02:02.110 schema points.
01:02:02.380 --> 01:02:05.898 I probably go to something like a through D that's like 1/3 of
01:02:05.898 --> 01:02:09.248 it, and I'll tell it to cover all those, and then I'll come
01:02:09.248 --> 01:02:11.370 back and I'll do F through let's say.
01:02:13.400 --> 01:02:16.846 F through products I would do that chunk and then I would come
01:02:16.846 --> 01:02:20.291 in and do this chunk that keeps it low enough that it it's not
01:02:20.291 --> 01:02:23.792 gonna break or or freak out or like sit there forever trying to
01:02:23.792 --> 01:02:26.800 like analyze and run all these tests at the same time.
01:02:27.870 --> 01:02:31.100 Excuse me, but the you know all that.
01:02:31.110 --> 01:02:33.610 It'll keep it from from doing all those that stuff crazy wise.
01:02:34.080 --> 01:02:36.846 But as it keeps building through and operating these tests
01:02:36.846 --> 01:02:39.800 through here, it's gonna keep extending our code coverage more
01:02:39.800 --> 01:02:42.660 and more, up to the point where it's actually covered stuff.
01:02:42.830 --> 01:02:46.559 And as we do this stuff, I can then see like, OK, what's really
01:02:46.559 --> 01:02:49.880 bad in these groups of what's really bad in my hotspots?
01:02:49.890 --> 01:02:54.502 What's really bad in my and my you know my workflow base that's
01:02:54.502 --> 01:02:57.240 not covered, that used to be covered.
01:02:57.250 --> 01:03:00.873 One point I had the workflow base like 96% coverage, but it's
01:03:00.873 --> 01:03:04.671 been a very long time since that happens, so coming through here
01:03:04.671 --> 01:03:08.353 individual tests don't take very long to run or even groups of
01:03:08.353 --> 01:03:11.800 them are even kind of shooting through when a really small
01:03:11.800 --> 01:03:14.430 tables like image types or things like that.
01:03:14.620 --> 01:03:17.001 They don't do a whole lot, so they're really quick to just
01:03:17.001 --> 01:03:18.010 kind of spin through the.
01:03:18.640 --> 01:03:18.760 Yeah.
01:03:19.640 --> 01:03:23.492 Umm, I'm going to let that keep running that kind of covers a
01:03:23.492 --> 01:03:26.350 lot of like the default and out of box tests.
01:03:26.920 --> 01:03:29.344 I will look this this code coverage running the background
01:03:29.344 --> 01:03:29.550 here.
01:03:29.640 --> 01:03:31.650 Hopefully my voice isn't breaking up a bunch.
01:03:35.010 --> 01:03:37.097 I before I move on to the extended tests where you're
01:03:37.097 --> 01:03:39.377 adding your own test or you're doing custom stuff for like
01:03:39.377 --> 01:03:41.928 providers, does anybody have any questions about the default test
01:03:41.928 --> 01:03:44.209 and what they're covering and why they're covering and how
01:03:44.209 --> 01:03:44.750 they're doing?
01:03:48.670 --> 01:03:49.890 No, I don't.
01:03:51.120 --> 01:03:53.643 And I'll say again, like, raise your hands if you're good to
01:03:53.643 --> 01:03:53.850 meet.
01:03:53.860 --> 01:03:54.500 Good to go on.
01:04:01.680 --> 01:04:02.350 Ohh.
01:04:03.100 --> 01:04:04.030 Uh.
01:04:05.100 --> 01:04:08.450 That's 3-4 Grego.
01:04:09.320 --> 01:04:09.970 I'm listening.
01:04:09.980 --> 01:04:11.470 I was in my kitchen grabbing a drink.
01:04:11.480 --> 01:04:13.260 I had to come running back to click the button.
01:04:14.100 --> 01:04:15.630 This is the James Gray podcast.
01:04:14.540 --> 01:04:14.880 Me too.
01:04:16.810 --> 01:04:20.450 Craig's just suffering because of JBM background in bed.
01:04:21.680 --> 01:04:24.040 Sorry, drag drag.
01:04:23.620 --> 01:04:26.556 Little did we know Gregg getting attacked by ninjas and we're
01:04:24.050 --> 01:04:24.700 What did I just say?
01:04:24.960 --> 01:04:27.915 Hey, I'm raising my hand for Greg, cause he's in other he's
01:04:26.556 --> 01:04:27.550 just laughing at him.
01:04:27.915 --> 01:04:29.590 shredding on some stuff, I think.
01:04:29.520 --> 01:04:30.210 OK.
01:04:30.760 --> 01:04:31.230 OK.
01:04:31.240 --> 01:04:32.710 Then we'll go ahead and move on.
01:04:33.060 --> 01:04:36.060 You could put your hands back down. Wow.
01:04:34.700 --> 01:04:37.120 I raise my hand, but I don't know what's going on anyways.
01:04:37.890 --> 01:04:38.420 Thank you, Greg.
01:04:38.810 --> 01:04:40.300 I have no idea what's going on.
01:04:41.320 --> 01:04:42.370 Sorry, I stepped away for a second.
01:04:41.390 --> 01:04:43.010 I just wanna walk in the sunshine a little bit longer.
01:04:43.990 --> 01:04:44.610 I got you back.
01:04:46.050 --> 01:04:48.988 OK, so I've covered a lot of the a lot of what's going on in
01:04:48.988 --> 01:04:50.240 where where it is and why.
01:04:50.250 --> 01:04:51.900 It's why it's there.
01:04:52.030 --> 01:04:54.699 I can go into more details about certain things if you guys want
01:04:54.699 --> 01:04:55.520 to bring it up more.
01:04:55.530 --> 01:04:56.890 Towards the end, we've got 30 minutes left.
01:04:56.900 --> 01:04:59.410 I'm gonna try and cover the extended testing here.
01:05:00.030 --> 01:05:03.219 While this stuff is running in the background, since I have
01:05:03.219 --> 01:05:06.461 done about there and tell this one to execute, so I'll cover
01:05:06.461 --> 01:05:06.780 those.
01:05:07.390 --> 01:05:10.726 So here is the account standard workflow extended where I have
01:05:10.726 --> 01:05:13.691 added custom tests for the accounts that are beyond the
01:05:13.691 --> 01:05:14.380 default ones.
01:05:14.890 --> 01:05:18.333 I'm going to move this off screen the way I have this
01:05:18.333 --> 01:05:19.800 screen back so we have.
01:05:20.930 --> 01:05:21.670 I'd like nuke.
01:05:21.680 --> 01:05:26.807 That's, you know, minimize that and I will cut that back to
01:05:26.807 --> 01:05:27.320 there.
01:05:27.330 --> 01:05:27.700 There we go.
01:05:28.230 --> 01:05:32.574 OK, so in the overridden version of it, I have modified the data
01:05:32.574 --> 01:05:36.050 so it would the default test will cover more stuff.
01:05:36.330 --> 01:05:37.600 I added account price points.
01:05:37.610 --> 01:05:40.738 I added notes and I added account contacts on to these
01:05:40.738 --> 01:05:44.150 things and then I have the update here saying that it needs
01:05:44.150 --> 01:05:47.619 to basically cause the other value to wipe or be reduced, or
01:05:47.619 --> 01:05:50.520 modify whatever the contents of the collection is.
01:05:50.870 --> 01:05:52.250 So that's the account contest one.
01:05:52.760 --> 01:05:54.990 It's actually hoping for like these special ones.
01:05:55.000 --> 01:05:56.030 Yes, this is what I want.
01:05:56.320 --> 01:06:00.517 This table this file should actually get renamed to meet the
01:06:00.517 --> 01:06:04.370 new standard, because this is should be like like this.
01:06:04.380 --> 01:06:07.950 Other ones are, but say special because it's special.
01:06:08.840 --> 01:06:10.550 Boom special.
01:06:12.880 --> 01:06:14.100 OK, now that it's special.
01:06:14.770 --> 01:06:18.592 Umm this one inherits the other one, but instead of operating
01:06:18.592 --> 01:06:22.352 those tests and bringing them all in, it brings in the first
01:06:22.352 --> 01:06:25.804 part of it and then you get to run wholly new stuff for
01:06:25.804 --> 01:06:29.440 whatever you're doing, so I'm having it add this extra one
01:06:29.440 --> 01:06:33.386 that says create with an account type ID not in the data should
01:06:33.386 --> 01:06:35.050 throw an invalid exception.
01:06:35.480 --> 01:06:39.273 This is an example of what used to be a theory is you would
01:06:39.273 --> 01:06:43.445 write a theory instead, and then for each theory you would put in
01:06:43.445 --> 01:06:45.910 one of the values that you would have.
01:06:46.220 --> 01:06:50.950 So I'll do this like this and then I'll select these three and
01:06:50.950 --> 01:06:55.380 then I'll go to these three and paste them that like that.
01:06:55.390 --> 01:06:57.220 And then we have like int Max value minus one.
01:06:57.230 --> 01:06:58.170 I don't know if it will accept this.
01:07:00.420 --> 01:07:04.800 It seems like it will as he would do that and then it would
01:07:04.800 --> 01:07:09.546 pass it into the so it says like a a death or well and value and
01:07:09.546 --> 01:07:13.050 then you would just do this one once like this.
01:07:17.520 --> 01:07:18.190 Weights.
01:07:18.200 --> 01:07:18.890 Boom.
01:07:19.040 --> 01:07:22.493 You would do your configure a weight, but I'm not going to
01:07:22.493 --> 01:07:25.830 type at the moment and then that part wouldn't be there.
01:07:25.840 --> 01:07:28.357 You would be doing this one thing and then for each of these
01:07:28.357 --> 01:07:30.916 five times it would pass in the value to the test and execute
01:07:30.916 --> 01:07:31.040 it.
01:07:31.050 --> 01:07:33.317 Ones like that, and if any of them failed, I would get my
01:07:33.317 --> 01:07:33.630 failure.
01:07:34.000 --> 01:07:36.961 The problem is that this shows up as five separate tests under
01:07:36.961 --> 01:07:39.499 a theory that's grouped a certain way inside the test
01:07:39.499 --> 01:07:42.320 editor, and it was one of the things that was causing it to
01:07:42.320 --> 01:07:44.670 have too many tests and it would make it blow up.
01:07:44.760 --> 01:07:46.580 So we don't use the theory because of that reason.
01:07:47.300 --> 01:07:51.611 Umm, but if I undo all of this and get it back to the way it
01:07:51.611 --> 01:07:54.720 was, that's the reason that we have a fact.
01:07:54.790 --> 01:07:57.510 And then inside that fact I have it executing different stuff.
01:07:57.790 --> 01:08:01.217 This is also kind of like the idea of like if I needed to run
01:08:01.217 --> 01:08:04.645 these in a particular order, I would do an async await on all
01:08:04.645 --> 01:08:08.128 of these individually, and then I basically instead of running
01:08:08.128 --> 01:08:11.666 at the same time, they would run in this order every time and I
01:08:11.666 --> 01:08:15.093 would have to have this be async in order to do this with the
01:08:15.093 --> 01:08:18.576 when all that basically says you all of you go run at the same
01:08:18.576 --> 01:08:21.948 time come back as fast as you can and then I'll call it good
01:08:21.948 --> 01:08:23.220 when everything's done.
01:08:23.730 --> 01:08:26.410 So we have that version and we have that running in that way.
01:08:27.050 --> 01:08:30.431 Ideally, for thread safety in, I could try to work out some
01:08:30.431 --> 01:08:33.869 system where all of this stuff gets added to a single thread
01:08:33.869 --> 01:08:36.180 queue and then tries to run or whatever.
01:08:36.190 --> 01:08:36.920 It's too advanced.
01:08:36.930 --> 01:08:38.270 It's not worth the effort.
01:08:38.950 --> 01:08:40.280 I don't think so.
01:08:40.290 --> 01:08:41.190 I haven't bothered doing that.
01:08:41.200 --> 01:08:43.972 Kind of thing I might do something like that for Phoenix
01:08:43.972 --> 01:08:46.988 that I'm not going to bother with it for the current version,
01:08:46.988 --> 01:08:49.907 so I have this stuff here and then it goes and executes the
01:08:49.907 --> 01:08:52.679 the actual test and you you'll see that familiar context
01:08:52.679 --> 01:08:55.306 profile name with a child container where we're later
01:08:55.306 --> 01:08:58.419 removing it inside there we have our mocking set up with custom
01:08:58.419 --> 01:08:59.830 tables that I've set up here.
01:08:59.920 --> 01:09:01.370 I tell it to run the mocking setup.
01:09:01.750 --> 01:09:05.230 I inject the database for the mock into the child container.
01:09:05.460 --> 01:09:08.030 I add our data model testing registry and the container.
01:09:08.420 --> 01:09:12.482 I replace the container and then I have my custom model and that
01:09:12.482 --> 01:09:16.232 I'm doing an assert throws on my create that has an invalid
01:09:16.232 --> 01:09:20.232 account type and says that it's not there or it comes back with
01:09:20.232 --> 01:09:23.420 whatever and you know blows up and does its thing.
01:09:23.480 --> 01:09:26.540 So this is my custom test that I'm executing with custom stuff.
01:09:27.070 --> 01:09:28.480 I'm doing the same thing here.
01:09:28.710 --> 01:09:32.020 I'm just calling create with a different status ID.
01:09:32.730 --> 01:09:35.784 I have stuff that exercises the account type IDs are not in the
01:09:35.784 --> 01:09:38.837 data and I have another one here that says studies that are not
01:09:38.837 --> 01:09:39.410 in the data.
01:09:39.450 --> 01:09:42.240 So this is just I'm adding tests that weren't built by the T4
01:09:42.240 --> 01:09:42.960 automated thing.
01:09:43.070 --> 01:09:44.700 Sometimes I have them here first.
01:09:44.710 --> 01:09:47.900 We're like, I'm building out what I'm going to do, and then I
01:09:47.900 --> 01:09:51.192 might generalize it and turn it into the T4 part so that things
01:09:51.192 --> 01:09:53.867 that would share this commonality could print their
01:09:53.867 --> 01:09:56.800 own copy of these tests into their own custom workflows.
01:09:57.380 --> 01:09:59.770 Umm, but I did do that.
01:09:59.780 --> 01:10:02.822 In this case, I just kept it here and did the thing that I'm
01:10:02.822 --> 01:10:03.770 doing here with it.
01:10:03.780 --> 01:10:04.390 So yay.
01:10:06.370 --> 01:10:06.960 And it comes back.
01:10:06.970 --> 01:10:08.210 And he does all of its custom stuff.
01:10:08.700 --> 01:10:12.088 Uh, a workflow that has a lot of customizations in it is gonna be
01:10:12.088 --> 01:10:12.550 products.
01:10:13.460 --> 01:10:16.046 So if I got a products and I go to the product special workflow
01:10:16.046 --> 01:10:16.450 test here.
01:10:17.740 --> 01:10:20.770 And you could see that I'm inheriting and then I do
01:10:20.770 --> 01:10:22.110 customizations to like.
01:10:22.120 --> 01:10:25.524 I'm overriding the get by ID test and then making it do all
01:10:25.524 --> 01:10:29.269 this other extra funky stuff and where because of the I don't use
01:10:29.269 --> 01:10:32.559 the default get endpoint in products I use this other one
01:10:32.559 --> 01:10:35.907 that has these other parameters on it for the call, so I'm
01:10:35.907 --> 01:10:39.424 overwriting the test and not call the default one because the
01:10:39.424 --> 01:10:41.070 default one gonna be trashed.
01:10:41.720 --> 01:10:44.961 It's gonna give me bad results, so I'm calling this one that
01:10:44.961 --> 01:10:48.361 does the extra stuff that I want to do, and then I do the extra
01:10:48.361 --> 01:10:51.495 asserts around whatever I'm going to do with that stuff by
01:10:51.495 --> 01:10:52.080 get by key.
01:10:52.140 --> 01:10:52.550 Same thing.
01:10:52.560 --> 01:10:55.054 I have a different version of it that has extra parameters versus
01:10:55.054 --> 01:10:55.810 the one that's like.
01:10:55.820 --> 01:10:59.533 Out of that you can say is out of box and I just notice here
01:10:59.533 --> 01:11:02.150 that this one is not doing argument names.
01:11:02.160 --> 01:11:04.540 I want to sue all the trailing arguments on it.
01:11:04.550 --> 01:11:05.010 There we go.
01:11:05.500 --> 01:11:08.210 So I can see that it has is vendor admin and vendor admin
01:11:08.210 --> 01:11:08.350 ID.
01:11:08.400 --> 01:11:11.298 I'm not passing anything to it, but it is the correct function
01:11:11.298 --> 01:11:14.104 of what I wanna call, so I'm calling this one instead of the
01:11:14.104 --> 01:11:15.070 default one in there.
01:11:15.620 --> 01:11:19.230 This one is some testing around like a variant master.
01:11:19.640 --> 01:11:21.857 This is not overwriting an existing test because there's
01:11:21.857 --> 01:11:22.830 nothing default about it.
01:11:22.920 --> 01:11:25.964 It's custom workflow that is only available to a product, so
01:11:25.964 --> 01:11:28.010 I writing a custom test that's doing it.
01:11:28.120 --> 01:11:31.610 You can see here I'm registering the context and telling it that
01:11:31.610 --> 01:11:34.832 if the context hasn't been run yet, then to build itself in
01:11:34.832 --> 01:11:36.980 memory, we write the container in here.
01:11:36.990 --> 01:11:39.260 Honestly, this part isn't really necessary anymore.
01:11:39.270 --> 01:11:44.175 I can just push the database into it and these days, but I
01:11:44.175 --> 01:11:45.090 have never.
01:11:45.130 --> 01:11:46.960 I never went back in, like rewrote all of these things.
01:11:46.970 --> 01:11:49.920 It wasn't as that was just extra work, because this stuff.
01:11:49.990 --> 01:11:52.700 So I call in and I say like pull out of the default data.
01:11:52.790 --> 01:11:55.028 The part that is the variant master and then do some stuff
01:11:55.028 --> 01:11:55.900 that was sort of stuff.
01:11:56.010 --> 01:11:59.249 Honestly, I should be doing more assets here that are around the
01:11:59.249 --> 01:12:01.990 fact that it is the variant master and like associated
01:12:01.990 --> 01:12:05.180 products that should be there or versus not that kind of thing.
01:12:05.410 --> 01:12:09.039 But I didn't do that, so it's just kind of like A to do thing
01:12:09.039 --> 01:12:11.380 on here to come in and take care of it.
01:12:11.530 --> 01:12:14.336 But we did try to at least somewhat exercise like the the
01:12:14.336 --> 01:12:17.143 possibility of that variant stuff, and I do wanna go back
01:12:17.143 --> 01:12:19.030 and get that more stuff taken care of.
01:12:19.280 --> 01:12:20.710 Same thing here for like a kit master.
01:12:20.720 --> 01:12:23.731 I'm just calling it a particular product and I would go do extra
01:12:23.731 --> 01:12:24.380 asserts on it.
01:12:25.110 --> 01:12:26.870 A key is not in the data.
01:12:27.300 --> 01:12:31.419 Uh, not there and then it should come back with a null, which is
01:12:31.419 --> 01:12:33.890 different than the norm in some cases.
01:12:34.160 --> 01:12:37.810 By SEO URL you know starting the data is there.
01:12:37.980 --> 01:12:41.200 What's a good customer?
01:12:41.210 --> 01:12:42.510 Has some custom inserts on it.
01:12:44.490 --> 01:12:48.915 We find one of those search for a category name, so this is
01:12:48.915 --> 01:12:53.341 calling a particular one with a particular category data of
01:12:53.341 --> 01:12:53.710 wine.
01:12:53.750 --> 01:12:56.806 Some of the products that are in the the dummy data are called
01:12:56.806 --> 01:12:59.960 wine, so I'm passing it in there and I'm expecting to get back 2
01:12:59.960 --> 01:13:02.580 results, so I'm making sure the filtering is working.
01:13:02.770 --> 01:13:06.519 So that's exercising some of the filtering for that thing I might
01:13:06.519 --> 01:13:06.690 be.
01:13:06.700 --> 01:13:09.367 I might have a bunch of different searches that would go
01:13:09.367 --> 01:13:12.267 through execute with different values on different properties
01:13:12.267 --> 01:13:15.121 of the search model in order to exercise them all on there I
01:13:15.121 --> 01:13:18.068 have one that like physically exercises the Git product review
01:13:18.068 --> 01:13:18.630 information.
01:13:18.640 --> 01:13:21.856 Just kind of proves that it comes back, which gives me code
01:13:21.856 --> 01:13:23.410 coverage around what that is.
01:13:23.420 --> 01:13:27.152 So if I go to that function, it's been covered by the thing
01:13:27.152 --> 01:13:27.650 already.
01:13:27.700 --> 01:13:30.649 It didn't cover this scenario, but it covered all of this, so
01:13:30.649 --> 01:13:33.741 this function at least have some coverage, which is nice, and if
01:13:33.741 --> 01:13:36.643 I want to find this function in here I can copy the name and
01:13:36.643 --> 01:13:38.070 then come over here and paste.
01:13:38.560 --> 01:13:41.777 Actually, if I do, if I just start typing, there goes when
01:13:41.777 --> 01:13:45.104 you start typing it brings up a search window and then I can
01:13:45.104 --> 01:13:46.140 paste inside there.
01:13:46.150 --> 01:13:49.293 It will show me that function and I can see that this function
01:13:49.293 --> 01:13:50.490 in the product workflow.
01:13:52.140 --> 01:13:54.320 It's kind of cut off because it's too narrow and we make it
01:13:54.320 --> 01:13:54.720 wider here.
01:13:56.160 --> 01:14:00.469 Product review information async this one is 7 out of 19 it is
01:14:00.469 --> 01:14:01.290 63% covered.
01:14:01.580 --> 01:14:05.063 So this part right here is another seven statements or
01:14:05.063 --> 01:14:08.673 logical steps of this function that has a total of 19 of
01:14:08.673 --> 01:14:10.890 logical steps that is not covered.
01:14:11.000 --> 01:14:13.557 So what I would really want is to have another test that would
01:14:13.557 --> 01:14:15.870 basically exercise this count is greater than 0 version.
01:14:16.580 --> 01:14:20.011 That way it hits both sides and then maybe I can bump this from
01:14:20.011 --> 01:14:23.443 7 remaining to like two or three remaining and get more of this
01:14:23.443 --> 01:14:24.730 coverage up to like 70%.
01:14:25.000 --> 01:14:27.951 That would be more appropriate average of the of a particular
01:14:27.951 --> 01:14:28.380 function.
01:14:28.610 --> 01:14:31.432 You can go through and do all the individual tests, but it
01:14:31.432 --> 01:14:34.111 depends on how you know how rigorous the thing actually
01:14:34.111 --> 01:14:35.020 needs to be tested.
01:14:35.030 --> 01:14:37.674 For every negative path, especially if there's a lot of
01:14:37.674 --> 01:14:39.940 negative paths for what you're doing on things.
01:14:39.950 --> 01:14:43.040 So you'll see that they'll end up being coverage on those
01:14:43.040 --> 01:14:45.810 things as by adding more tests, that block is done.
01:14:45.820 --> 01:14:48.523 I'm going to tell the last block of coverage to go ahead and run
01:14:48.523 --> 01:14:49.480 in the background here.
01:14:49.570 --> 01:14:52.653 While we're working, I can see that just by physically calling
01:14:52.653 --> 01:14:55.393 it exercising, it didn't really do anything customer or
01:14:55.393 --> 01:14:56.470 asserting about stuff.
01:14:56.510 --> 01:14:59.235 The fact that it ran and gave me the result is a verification
01:14:59.235 --> 01:15:01.520 that it did something it didn't throw an exception.
01:15:01.530 --> 01:15:02.940 It didn't do some other weird stuff.
01:15:03.050 --> 01:15:04.520 It wasn't null when it came back.
01:15:04.650 --> 01:15:05.760 I got a value back.
01:15:06.190 --> 01:15:09.571 I could further assert more things on the model that came
01:15:09.571 --> 01:15:13.068 back, and I probably should in order to assert that they're
01:15:13.068 --> 01:15:16.798 valid, but for the time being I was happy enough just getting a
01:15:16.798 --> 01:15:20.296 good result back at all, which gave me some reasonable code
01:15:20.296 --> 01:15:23.734 coverage like for a product, but no reviews and some other
01:15:23.734 --> 01:15:27.173 coverage that's gonna happen here again, what's a good one
01:15:27.173 --> 01:15:29.680 that has a bunch of custom stuff going on?
01:15:33.250 --> 01:15:36.720 She in range between zero and four.
01:15:37.190 --> 01:15:38.360 That is not right.
01:15:38.370 --> 01:15:39.320 Somebody changed that.
01:15:39.330 --> 01:15:41.807 That should actually come back with the same number every time
01:15:41.807 --> 01:15:42.830 somebody messed with that.
01:15:44.410 --> 01:15:44.650 No.
01:15:46.050 --> 01:15:48.230 Damn, I need to rewrite that back to me.
01:15:48.240 --> 01:15:48.420 Was.
01:15:50.190 --> 01:15:54.031 Let's see here is customization so that the generating a product
01:15:54.031 --> 01:15:57.635 model like create a whole bunch of properties on it like SEO
01:15:57.635 --> 01:15:59.940 data and packages and stuff like that.
01:16:00.030 --> 01:16:03.921 So it's a more valuable one and then some of my tests here
01:16:03.921 --> 01:16:08.077 verify like did the product to get added to the products table
01:16:08.077 --> 01:16:12.034 once and did the save changes get called at least once with
01:16:12.034 --> 01:16:15.728 the mocks so that I can verify that it went through and
01:16:15.728 --> 01:16:18.300 actually saved it to it appropriately.
01:16:18.390 --> 01:16:20.776 Because we've been doing customizations and modifications
01:16:20.776 --> 01:16:23.203 to how the part workflow works for creates an upskirts and
01:16:23.203 --> 01:16:25.713 things I wanted to make sure that it still covered that same
01:16:25.713 --> 01:16:25.960 stuff.
01:16:26.290 --> 01:16:29.051 So we have those, you know, kind of the modifications that you
01:16:29.051 --> 01:16:31.900 check you you can't necessarily verify that it's actually in the
01:16:31.900 --> 01:16:34.442 database because it's a fake database, but you can verify
01:16:34.442 --> 01:16:37.115 that you called the function that would have added it to the
01:16:37.115 --> 01:16:37.510 database.
01:16:37.730 --> 01:16:40.878 And then another one that would have called the save changes on
01:16:40.878 --> 01:16:43.780 it in there, so you could verify that kind of information.
01:16:44.290 --> 01:16:46.624 So there's work arounds and weirdness around how some of the
01:16:46.624 --> 01:16:48.882 stuff will end up working when you get down into the nitty
01:16:48.882 --> 01:16:49.380 gritty of it.
01:16:49.970 --> 01:16:52.250 But for the most part, it's fairly straightforward.
01:16:52.260 --> 01:16:54.595 You just kind of call it and then just assume that it's gonna
01:16:54.595 --> 01:16:56.779 go through and then if you didn't get an exception coming
01:16:56.779 --> 01:16:58.700 back, that's automatically going to fail the test.
01:16:58.710 --> 01:17:02.122 If it did and you weren't catching and looking for an
01:17:02.122 --> 01:17:06.167 exertion, they're sort of, you know, sharing and exception then
01:17:06.167 --> 01:17:10.085 it would come through and give you your result, like this one
01:17:10.085 --> 01:17:13.624 here is it creates that specifically exercises the part
01:17:13.624 --> 01:17:15.330 associations modifications.
01:17:15.440 --> 01:17:20.103 So this one is causing different associations to to sections of
01:17:20.103 --> 01:17:24.328 the code to physically get exercised that the default one
01:17:24.328 --> 01:17:26.150 wouldn't have covered on.
01:17:26.160 --> 01:17:29.451 Here I could put this data and this and other data into the
01:17:29.451 --> 01:17:32.797 other one, but you kind of want to isolate your test down as
01:17:32.797 --> 01:17:36.088 much as you can so that they aren't trying to test too many
01:17:36.088 --> 01:17:39.544 things at once because it makes it harder to determine where a
01:17:39.544 --> 01:17:42.506 particular problem is coming from and what's actually
01:17:42.506 --> 01:17:46.071 covering that test and which one was going to cause the failover
01:17:46.071 --> 01:17:46.510 to pass.
01:17:46.520 --> 01:17:49.199 And you might be causing more things to fail, or more
01:17:49.199 --> 01:17:51.680 individual tests to fail when you didn't need to.
01:17:52.150 --> 01:17:52.660 Kind of thing.
01:17:52.670 --> 01:17:55.822 It's kind of becomes a diminishing returns, some other
01:17:55.822 --> 01:17:58.000 things that you can say for patterns.
01:17:58.770 --> 01:18:02.250 I got manufacturers checking I got vendor product checking.
01:18:04.890 --> 01:18:07.271 And then I have my other ones that are all doing extra weird
01:18:07.271 --> 01:18:07.700 stuff here.
01:18:07.710 --> 01:18:08.970 I got updates and I got other stuff here.
01:18:10.270 --> 01:18:10.960 Let's see.
01:18:11.110 --> 01:18:11.760 This is benders.
01:18:11.770 --> 01:18:14.774 Associations on updates deactivates verifying that they
01:18:14.774 --> 01:18:18.262 are actually did you activating the thing, and then it goes back
01:18:18.262 --> 01:18:21.803 and asks for it again, and if it comes back and it doesn't have a
01:18:21.803 --> 01:18:25.183 null on the OR a negative value on the negative value, a false
01:18:25.183 --> 01:18:28.510 on the active state, then we know that they didn't deactivate
01:18:28.510 --> 01:18:31.729 it correctly and I have seen people like go in and do stuff
01:18:31.729 --> 01:18:34.680 and like they didn't write it correctly so they broke.
01:18:36.510 --> 01:18:37.160 Excuse me.
01:18:37.790 --> 01:18:40.844 So and then we have some stuff that covers some of the custom
01:18:40.844 --> 01:18:43.750 functions that are like get for selling products or search
01:18:43.750 --> 01:18:44.440 revisit order.
01:18:44.450 --> 01:18:47.633 But this one got skipped because that was only really relevant to
01:18:47.633 --> 01:18:50.527 a particular client and was never running again and it kind
01:18:50.527 --> 01:18:52.360 of broke by the wayside at one point.
01:18:52.370 --> 01:18:54.030 So I got rid of it.
01:18:55.370 --> 01:18:58.463 Search recently viewed, which uses some of like the the
01:18:58.463 --> 01:19:01.556 personalization stuff and is supposed to come back with
01:19:01.556 --> 01:19:02.440 certain results.
01:19:02.630 --> 01:19:05.209 So that comes back with, you know, those kinds of things and
01:19:05.209 --> 01:19:07.830 and gives us coverage into extra tables and things like that.
01:19:08.950 --> 01:19:11.060 Our test code coverage run is almost done.
01:19:16.910 --> 01:19:19.913 But yeah, if you're to come in and write a test for the most
01:19:19.913 --> 01:19:22.915 part, a lot of these things like find the test that would be
01:19:22.915 --> 01:19:25.820 closest to the relevance of what you're you're working in.
01:19:25.830 --> 01:19:27.920 Like if you're working with, something's gonna be covering a
01:19:27.920 --> 01:19:29.360 customization for client around products.
01:19:29.690 --> 01:19:31.160 You would come in and go find like a product.
01:19:31.170 --> 01:19:31.500 Test.
01:19:31.750 --> 01:19:34.070 That was like a get a product or whatever you were doing.
01:19:34.690 --> 01:19:37.785 Umm and copy that test so that you have a good starting place
01:19:37.785 --> 01:19:40.780 that will already have like the context profile name in it.
01:19:40.930 --> 01:19:43.555 The fact that it's creating a child container, a mocking
01:19:43.555 --> 01:19:46.457 setup, the child container that gets configured with that mock
01:19:46.457 --> 01:19:48.760 setup, getting pushed into it, they did them all.
01:19:48.770 --> 01:19:52.065 Testing registry, removing the container assertions and
01:19:52.065 --> 01:19:53.360 creating the workflow.
01:19:53.590 --> 01:19:56.522 All that stuff getting in there, the more you can kind of cover
01:19:56.522 --> 01:19:59.499 and like like, you know, use the tools that are already in front
01:19:59.499 --> 01:19:59.820 of you.
01:20:00.050 --> 01:20:02.452 The less you'll have to go in and try and figure out on your
01:20:02.452 --> 01:20:04.460 own for like, well, how do I set this up on there?
01:20:04.470 --> 01:20:06.820 I'm go and recover these five because they got dirt.
01:20:06.830 --> 01:20:07.380 They became dirty.
01:20:13.020 --> 01:20:16.140 And we've got 12 here that are ignored because of various
01:20:16.140 --> 01:20:19.529 things like expand all and show them so that I can remove them
01:20:19.529 --> 01:20:20.390 from my session.
01:20:22.300 --> 01:20:24.892 You don't ever want to actually remove during the session
01:20:24.892 --> 01:20:25.250 running.
01:20:25.260 --> 01:20:26.950 You wanna do it when it stopped?
01:20:27.420 --> 01:20:30.490 Because it can throw off the counts of at the top.
01:20:30.500 --> 01:20:34.144 If you do that, it just behaves weirdly when that happens, so
01:20:34.144 --> 01:20:37.905 I'm gonna let it run, and then when it finishes running, I will
01:20:37.905 --> 01:20:39.610 delete these from my session.
01:20:44.270 --> 01:20:46.145 It should be pretty quick because it's just five small
01:20:46.145 --> 01:20:46.350 tests.
01:20:49.660 --> 01:20:51.050 Yep, Dan and three down zero.
01:20:51.100 --> 01:20:54.273 OK, now that I know that stopped because I have buttons telling
01:20:54.273 --> 01:20:57.346 me to offer to run it, I will remove those selected tests and
01:20:57.346 --> 01:21:00.370 then I'll go over to my main view and collapse all and I can
01:21:00.370 --> 01:21:01.610 see all of my good tests.
01:21:01.760 --> 01:21:03.590 54840 out of 4840 passing.
01:21:03.600 --> 01:21:05.090 I know that they're all inside here.
01:21:05.280 --> 01:21:07.369 Looks like this thing is saying that some of my tests are not
01:21:07.369 --> 01:21:08.380 covered like one of them here.
01:21:09.410 --> 01:21:11.563 Whenever you change something and like this this snapshot
01:21:11.563 --> 01:21:12.380 things is out of date.
01:21:12.450 --> 01:21:15.830 You can tell it to recover that stuff so I can tell it to you.
01:21:17.180 --> 01:21:18.010 I won't talk to you.
01:21:19.160 --> 01:21:20.090 Cover that.
01:21:20.100 --> 01:21:20.670 Test.
01:21:21.260 --> 01:21:24.144 That should make it run that one test again and do that
01:21:24.144 --> 01:21:27.337 sometimes, though, if you change something and it thinks that
01:21:27.337 --> 01:21:30.632 it's that it's somehow modifying all the tests, it will make it
01:21:30.632 --> 01:21:30.890 like.
01:21:30.900 --> 01:21:34.826 Try to run all 4839 again, which is really annoying, so be
01:21:34.826 --> 01:21:36.490 careful about that thing.
01:21:37.280 --> 01:21:40.166 But yeah, it's usually OK and then I'll get your thing that
01:21:40.166 --> 01:21:43.245 says that your test coverage is clean and then now that we have
01:21:43.245 --> 01:21:46.036 that, I have a total test coverage of the entire solution
01:21:46.036 --> 01:21:47.960 at 41%, which is harder than I thought.
01:21:48.140 --> 01:21:48.740 That's pretty good.
01:21:49.510 --> 01:21:52.821 Umm, but you can see that we've exercised a huge amount of stuff
01:21:52.821 --> 01:21:56.133 in like models of mapping a huge budget stuff in the data access
01:21:56.133 --> 01:21:59.190 layer for just talking to the interfaces and just literally
01:21:59.190 --> 01:22:00.820 exercising properties on models.
01:22:00.950 --> 01:22:04.480 It's covering a lot of our code base by doing that and then like
01:22:04.480 --> 01:22:07.847 the business logic layer where the workflows are, we have 34%
01:22:07.847 --> 01:22:10.780 coverage and then the providers in total we have 13%.
01:22:10.790 --> 01:22:14.553 We have a bunch of providers that literally have no coverage
01:22:14.553 --> 01:22:16.280 or near no coverage on them.
01:22:16.290 --> 01:22:17.520 So like it's just running the registry.
01:22:17.530 --> 01:22:18.220 That's all it did.
01:22:18.270 --> 01:22:20.350 It didn't even like call anything else.
01:22:21.290 --> 01:22:22.540 Is something valid like?
01:22:22.550 --> 01:22:25.220 It's not even doing anything real that searching one.
01:22:25.230 --> 01:22:28.040 However, I do have tests for because I had tests for them.
01:22:28.950 --> 01:22:34.399 I get cool stuff if I double click one of these things, it's
01:22:34.399 --> 01:22:39.580 going to give me, I swear and actual code coverage there.
01:22:39.790 --> 01:22:43.580 Here's one of the sessions, this actually covering it and I could
01:22:43.580 --> 01:22:46.910 right click this area and say the show me the test that's
01:22:46.910 --> 01:22:48.920 covering it show in test Explorer.
01:22:50.820 --> 01:22:52.480 Let's see which winner was in that open up.
01:22:53.840 --> 01:22:56.604 One of these is supposed to like show me the the test that covers
01:22:56.604 --> 01:22:56.730 it.
01:22:56.780 --> 01:22:59.316 OK, so I had a little margin part here that says these are
01:22:59.316 --> 01:23:01.895 all tests that were physically ran through this part of the
01:23:01.895 --> 01:23:02.110 code.
01:23:02.160 --> 01:23:04.542 So I can double click one of these tests and we'll show me
01:23:04.542 --> 01:23:05.390 the test that did it.
01:23:05.500 --> 01:23:08.785 So if I don't like what my code coverage was, I can do to modify
01:23:08.785 --> 01:23:09.290 that test.
01:23:09.440 --> 01:23:12.419 Or I know that I'm in the right place to like copy this test and
01:23:12.419 --> 01:23:15.353 make another one with different modification that would make it
01:23:15.353 --> 01:23:18.195 go through one of these great paths with different values, so
01:23:18.195 --> 01:23:21.129 that would be a way of going in and and verifying that stuff is
01:23:21.129 --> 01:23:23.926 is, you know, running through the appropriate stuff and then
01:23:23.926 --> 01:23:24.980 I'll change my results.
01:23:24.990 --> 01:23:27.656 And you know, over to accordingly to on that other
01:23:27.656 --> 01:23:30.897 test to match what it's gonna do and I'll have increased code
01:23:30.897 --> 01:23:32.570 coverage in this place of stuff.
01:23:32.580 --> 01:23:34.030 So I would just go through and I would.
01:23:34.460 --> 01:23:37.038 I would probably copy a test like that one, populate new
01:23:37.038 --> 01:23:39.616 stuff into it, giving it a different name and different,
01:23:39.616 --> 01:23:42.420 you know, set of values that might have different table data.
01:23:42.430 --> 01:23:46.045 It might have different results to go verify for how many
01:23:46.045 --> 01:23:49.846 results that were supposed to come back, that kind of stuff,
01:23:49.846 --> 01:23:52.090 and then I'm good and close it out.
01:23:52.940 --> 01:23:56.440 I see here these tests actually have stuff to the test output
01:23:56.440 --> 01:23:59.827 helper helper, so that's a good one that I can show uh that
01:23:59.827 --> 01:24:03.497 console data basically, instead of going to the console, it came
01:24:03.497 --> 01:24:06.941 out here and you can see how it is inside the thing here and
01:24:06.941 --> 01:24:10.215 notice how it basically just JSON dumped a bunch of stuff
01:24:10.215 --> 01:24:13.941 here I'm going to go through and actually like explain what these
01:24:13.941 --> 01:24:17.498 things are, but I have all that data and content in here and I
01:24:17.498 --> 01:24:20.829 make sure that came back with stuff I say I have some like
01:24:20.829 --> 01:24:23.200 typos in somewhere but he's a quiet typo.
01:24:24.210 --> 01:24:25.000 Maybe I'm crazy.
01:24:25.070 --> 01:24:27.439 My eyes are playing tricks on me and then I'm exiting there at
01:24:27.439 --> 01:24:27.740 the end.
01:24:28.210 --> 01:24:30.892 If this data is too long, there is the like a, but there's a
01:24:30.892 --> 01:24:33.531 thing that will show you the stack trace Explorer that will
01:24:33.531 --> 01:24:36.170 show you a large review that with a larger character limit.
01:24:37.300 --> 01:24:39.260 Where you can see them, the whole thing pop in.
01:24:40.000 --> 01:24:42.950 But this one I've got my setting high enough that I'm it's
01:24:42.950 --> 01:24:46.000 allowed to show the whole thing, even though that was really
01:24:46.000 --> 01:24:46.250 long.
01:24:46.560 --> 01:24:48.710 So this is the testing and all that stuff.
01:24:48.720 --> 01:24:50.670 There only like a couple of minutes left.
01:24:51.520 --> 01:24:53.912 Anything you guys kinda want me to cover or cover a specific
01:24:53.912 --> 01:24:55.560 area or shows how something worked again?
01:25:04.480 --> 01:25:05.590 I see Tristan raising a hand.
01:25:05.600 --> 01:25:07.841 Don't know if it's because you ready for me to move on or
01:25:07.841 --> 01:25:10.120 because I don't have anything else on the cover right now.
01:25:11.180 --> 01:25:11.870 I was.
01:25:11.950 --> 01:25:14.124 I did have a question, but I was gonna leave it for that if
01:25:14.124 --> 01:25:15.030 anyone else has anything.
01:25:17.940 --> 01:25:18.290 So.
01:25:18.050 --> 01:25:19.690 Looks like you're looks like you're good.
01:25:20.890 --> 01:25:24.668 I was actually curious if you guys have thought of how we
01:25:24.668 --> 01:25:28.576 would be handling tests in a Phoenix, cause I know a lot of
01:25:28.576 --> 01:25:30.530 these are generated right? So?
01:25:31.110 --> 01:25:34.567 We have only spent a little bit of time on unit testing and
01:25:34.567 --> 01:25:37.793 Phoenix UM, we have identified that we would we will be
01:25:37.793 --> 01:25:41.481 switching to end unit because as better .net core support among
01:25:41.481 --> 01:25:42.230 other things.
01:25:42.660 --> 01:25:43.050 Mm-hmm.
01:25:44.400 --> 01:25:48.698 But right now, so much stuff in the Phoenix code base is still
01:25:48.698 --> 01:25:53.064 in flux that it's tough to like, really start building out unit
01:25:53.064 --> 01:25:56.270 tests for things that are constantly changing.
01:25:56.820 --> 01:25:57.330 Yeah, yeah.
01:25:57.160 --> 01:26:02.184 Umm, so it's there's a a handful of questions we still are trying
01:26:02.184 --> 01:26:06.675 to answer in terms of UM, dependency injection in the unit
01:26:06.675 --> 01:26:11.395 tests and ultimately a big part of this is gonna come down to
01:26:11.395 --> 01:26:16.038 me, just me and or James just spending time researching, uh,
01:26:16.038 --> 01:26:20.758 proper unit testing methodology in net core and familiarizing
01:26:20.758 --> 01:26:25.097 ourselves with that process looks like as opposed to how
01:26:22.600 --> 01:26:22.830 Umm.
01:26:25.097 --> 01:26:29.284 it's done NET Framework and and ideally we just follow
01:26:29.284 --> 01:26:34.003 relatively standard practice UM and adjust only where we need
01:26:34.003 --> 01:26:38.190 to, but we haven't really identified that process yet.
01:26:40.790 --> 01:26:44.009 Ohh good, I was curious if you guys have thought about it at
01:26:44.009 --> 01:26:44.220 all.
01:26:44.270 --> 01:26:45.370 So yeah, cool.
01:26:45.560 --> 01:26:48.800 I do have some tests.
01:26:51.640 --> 01:26:55.517 So I one of the things that I have actually built is like a
01:26:55.517 --> 01:26:59.588 FedEx shipping rates provider for a pipeline into how this new
01:26:59.588 --> 01:27:00.880 stuff is gonna work.
01:27:01.140 --> 01:27:05.904 So if I create a new session that has this code in it, these
01:27:05.904 --> 01:27:10.824 are in unit tests instead of X unit tests and I have so so any
01:27:10.824 --> 01:27:15.510 it has a few things like I could put this description here.
01:27:15.520 --> 01:27:16.510 This is a live test.
01:27:16.600 --> 01:27:20.221 This test will not run unless you specifically tell this test
01:27:20.221 --> 01:27:20.630 to run.
01:27:20.820 --> 01:27:22.100 It won't run when you tell it to run.
01:27:22.110 --> 01:27:25.912 All because I don't want it to and that's a nice little tag
01:27:25.912 --> 01:27:28.890 feature that Internet has that xunit does not.
01:27:29.470 --> 01:27:32.640 And descriptions to the test of what this test is trying to
01:27:32.640 --> 01:27:33.750 cover, which is cool.
01:27:34.620 --> 01:27:36.530 I'm looking into like it's.
01:27:36.540 --> 01:27:39.880 This is Matt mocking the uh HTTP client.
01:27:39.890 --> 01:27:42.114 Basically with with the replies would be if I were to hit
01:27:42.114 --> 01:27:42.920 particular endpoints.
01:27:42.990 --> 01:27:44.800 Someone actually hitting Fedex's API?
01:27:45.570 --> 01:27:49.086 I haven't doing what they're examples show, is the example
01:27:45.950 --> 01:27:46.150 Umm.
01:27:49.086 --> 01:27:52.721 response for stuff, and then I'm asserting, you know, assert
01:27:52.721 --> 01:27:56.296 multiple and then you assert that I think that they they do
01:27:56.296 --> 01:28:00.229 this so that the pattern is, uh, any each of these are allowed to
01:28:00.229 --> 01:28:03.983 fail and they were allowed to add themselves to the one assert
01:28:03.983 --> 01:28:07.856 there so that you don't just go, you know, fail and then move on
01:28:07.856 --> 01:28:08.810 to the next one.
01:28:08.820 --> 01:28:11.497 And it fails and then this fails and then this fails and this
01:28:11.497 --> 01:28:12.490 fails on down the line.
01:28:12.580 --> 01:28:15.718 It will actually check all of these things inside here and
01:28:15.718 --> 01:28:18.803 gather them together and return them at once for the same
01:28:18.803 --> 01:28:20.080 multiple, which is cool.
01:28:21.210 --> 01:28:23.807 We don't do that over in the xunit side, but that way you can
01:28:23.807 --> 01:28:26.573 not have to iterate your test as often you can just go, you know,
01:28:26.573 --> 01:28:28.500 all of the stuff can happen at the same time.
01:28:28.510 --> 01:28:31.427 So I'm gonna check them at the same time and then I have one
01:28:31.427 --> 01:28:34.583 here that says takes the results the first one and then check all
01:28:34.583 --> 01:28:36.400 the stuff about that result on there.
01:28:36.490 --> 01:28:40.834 But in here I have this this test here running and and they
01:28:40.834 --> 01:28:42.210 could all run here.
01:28:42.220 --> 01:28:45.400 So I told this to run all but the FedEx tests.
01:28:45.730 --> 01:28:47.632 It's gonna ignore that one because it had to be run
01:28:47.632 --> 01:28:50.047 explicitly, but the other is all pass and they're all super duper
01:28:50.047 --> 01:28:50.230 fast.
01:28:51.550 --> 01:28:54.050 But when I run it with null input, I can get back
01:28:54.050 --> 01:28:56.800 particularly particular responses, and I verified that
01:28:56.800 --> 01:28:59.350 the pipe you know loaded correctly and that it was
01:28:59.350 --> 01:29:02.400 supposed to throw a particular exception and all that stuff.
01:29:02.410 --> 01:29:06.122 So I do have some tests in here and they are built into their
01:29:06.122 --> 01:29:09.594 own testing project that covers exactly that pipeline and
01:29:09.594 --> 01:29:11.450 exactly that way if I cover it.
01:29:14.180 --> 01:29:17.845 And my code coverage on the FedEx test was super high
01:29:17.845 --> 01:29:18.320 before.
01:29:18.330 --> 01:29:19.470 I don't know if it's still is.
01:29:20.510 --> 01:29:23.210 Other stuff has changed in there should still be pretty good
01:29:23.210 --> 01:29:23.520 though.
01:29:24.910 --> 01:29:25.130 Yeah.
01:29:27.460 --> 01:29:28.300 I'll let it run.
01:29:33.650 --> 01:29:34.340 There we go.
01:29:34.990 --> 01:29:39.105 So it's exercising with confidence where my plugins and
01:29:39.105 --> 01:29:41.750 I made that wider so I can do that.
01:29:40.690 --> 01:29:43.948 98% coverage on the shipping plugin, though that's pretty
01:29:42.370 --> 01:29:42.560 Yeah.
01:29:43.890 --> 01:29:44.200 Yeah.
01:29:43.948 --> 01:29:44.510 damn good.
01:29:44.210 --> 01:29:47.504 For for, for FedEx by itself, there's only four spots that are
01:29:47.504 --> 01:29:50.327 not covered, and it's specifically this error message
01:29:50.327 --> 01:29:50.850 procedure.
01:29:50.860 --> 01:29:54.840 I'll turn on my highlighting this path and this path that are
01:29:54.840 --> 01:29:55.610 not covered.
01:29:56.080 --> 01:29:57.810 Those create four spots.
01:29:56.600 --> 01:29:59.390 And like it literally everything else is, yeah.
01:29:59.600 --> 01:30:00.270 Yeah.
01:30:00.600 --> 01:30:03.023 So I know that I'm damn well exercising this thing now,
01:30:03.023 --> 01:30:04.710 trying to get these two spots covered.
01:30:05.000 --> 01:30:08.270 That's where I would say like, OK, you've got it 98% covered.
01:30:08.520 --> 01:30:11.395 These couple of other paths that are in the negative path are
01:30:11.395 --> 01:30:14.270 probably a little too much to try and write another test for.
01:30:14.400 --> 01:30:18.206 If you want to sure, but I'm not going to ask you to do it right
01:30:18.206 --> 01:30:21.719 there, because even then it's still 86% covered on the main
01:30:21.719 --> 01:30:22.070 thing.
01:30:22.460 --> 01:30:26.020 So that's a lot to handle it and already covered UPS.
01:30:26.030 --> 01:30:29.416 I have coverage for it but UPS the one doesn't actually work
01:30:29.416 --> 01:30:32.636 right now and like I haven't written the ones for the the
01:30:32.636 --> 01:30:35.800 minimum rate one besides the main like exercising 1 yet.
01:30:35.670 --> 01:30:35.770 Yeah.
01:30:35.810 --> 01:30:37.450 So I need to do that.
01:30:37.210 --> 01:30:39.800 Which, by the way for some of the neat stuff.
01:30:39.850 --> 01:30:43.753 Uh, for those that are seeing a little bit of this maybe for the
01:30:43.753 --> 01:30:47.537 first time or first time in a while U M one of the things that
01:30:47.537 --> 01:30:51.441 we've been working on, Umm is as you can see a shipping provider
01:30:51.441 --> 01:30:55.224 which seems arbitrary, but the thought process there was let's
01:30:55.224 --> 01:30:58.707 start implementing like actual functionality like porting
01:30:58.707 --> 01:31:02.130 plugins or providers from SEF into plugins in Phoenix to
01:31:02.130 --> 01:31:05.554 exercise the architecture and figure out what we need to
01:31:05.554 --> 01:31:09.277 change and not change and all that kind of stuff. And to just
01:31:09.277 --> 01:31:13.001 start getting an idea of what it's like to actually work with
01:31:13.001 --> 01:31:16.244 the work, with it as a framework, umm. And so some of
01:31:16.244 --> 01:31:19.967 the cool things that came up while we did that uh to the neat
01:31:19.967 --> 01:31:23.030 things that I can think of off the top of my head.
01:31:23.320 --> 01:31:27.223 The first that James had was parallel pipelines or parallel
01:31:27.223 --> 01:31:31.126 pipeline steps that make it so that every hook you add to a
01:31:31.126 --> 01:31:34.769 pipeline they all run in parallel and return the result
01:31:34.769 --> 01:31:35.550 as an array.
01:31:36.520 --> 01:31:39.846 So we're using that for the actual collection of rate
01:31:39.846 --> 01:31:43.664 quotes, so calling out to UPS, calling out the FedEx, calling
01:31:43.664 --> 01:31:47.421 out to any other third party APIs, all that actually happens
01:31:47.421 --> 01:31:48.160 in parallel.
01:31:48.810 --> 01:31:53.690 And then the results from that are fed into a separate pipeline
01:31:53.690 --> 01:31:58.265 that allows you to hook in and deal with all of the results
01:31:58.265 --> 01:31:59.790 after the fact. Umm.
01:32:00.010 --> 01:32:02.150 Then one of the and then the second piece of that.
01:32:02.160 --> 01:32:02.870 That's really cool.
01:32:02.880 --> 01:32:10.088 Basically, is the, UM, uh. The they're effectively 2 primary
01:32:10.088 --> 01:32:11.270 pipelines.
01:32:11.280 --> 01:32:14.466 There's collect rate quotes which goes out and gets them
01:32:14.466 --> 01:32:15.920 from third party services.
01:32:15.930 --> 01:32:17.120 USPS FedEx, UPS.
01:32:17.890 --> 01:32:21.180 Umm, you know, I can't think of any lumis, et cetera.
01:32:21.230 --> 01:32:24.436 All the other ones, umm, that goes and gets all those in
01:32:24.436 --> 01:32:26.180 parallel, brings them together.
01:32:26.390 --> 01:32:29.169 That's step one of the get shipping rates pipeline, which
01:32:29.169 --> 01:32:32.140 is a serial pipeline, a standard you know one step at a time.
01:32:32.920 --> 01:32:36.420 It returns those pipes or those results into the pipeline and
01:32:36.420 --> 01:32:39.130 the next step in that can be anything you want.
01:32:39.420 --> 01:32:43.060 In our case, we've already built a couple of really cool ones,
01:32:43.060 --> 01:32:46.528 such as this really interesting one I think is minimum rate
01:32:46.528 --> 01:32:46.990 amounts.
01:32:47.000 --> 01:32:50.609 Pipe the something that we've built manually into several
01:32:50.609 --> 01:32:54.467 shipping providers and stuff is functionality to say that UPS
01:32:54.467 --> 01:32:58.201 ground, even though maybe UPS comes back and says that it's
01:32:58.201 --> 01:33:02.121 $12.00 by the time the client actually gets around to shipping
01:33:02.121 --> 01:33:04.610 something, it probably costs them more.
01:33:04.620 --> 01:33:04.990 Maybe like.
01:33:13.120 --> 01:33:13.810 We lost your audio.
01:33:17.820 --> 01:33:18.660 We lost Brendan.
01:33:18.670 --> 01:33:19.710 Yeah, ISPD.
01:33:18.670 --> 01:33:20.390 He'll be back in like 30 seconds.
01:33:19.680 --> 01:33:20.260 Yeah, he'll.
01:33:20.320 --> 01:33:21.670 He'll be back in a SEC, he said.
01:33:21.680 --> 01:33:24.773 It he said in the general channel earlier that that's
01:33:24.773 --> 01:33:26.720 happening to him alone right now.
01:33:25.960 --> 01:33:28.090 Did you post the link to this in the chat?
01:33:28.100 --> 01:33:30.240 If you don't mind, this is awesome.
01:33:29.840 --> 01:33:33.120 Uh, this is the only chart I have in here right now.
01:33:31.260 --> 01:33:31.630 It was cool.
01:33:34.250 --> 01:33:37.750 Umm but yeah, this is this is the one.
01:33:34.310 --> 01:33:35.240 OK, I'm back.
01:33:35.290 --> 01:33:35.880 Sorry.
01:33:36.020 --> 01:33:36.940 Friends of mine.
01:33:36.040 --> 01:33:37.780 Yeah, it was.
01:33:37.790 --> 01:33:41.475 It was precisely what you said it was, but anyway, now we don't
01:33:41.475 --> 01:33:44.873 have to build that kind of minimum rate functionality into
01:33:44.873 --> 01:33:47.580 every individual shipping provider separately.
01:33:47.910 --> 01:33:50.684 It can be a pipeline that hooks in after the fact and applies
01:33:50.684 --> 01:33:53.592 it, and then James also built it out where there's settings that
01:33:53.592 --> 01:33:56.097 you can say that for different for different rates from
01:33:56.097 --> 01:33:58.692 different providers, there's different minimum or maximum
01:33:58.692 --> 01:34:01.645 amounts minimums by minimums and maximums by percentage, like all
01:34:01.645 --> 01:34:03.390 kinds of different settings and stuff.
01:34:03.450 --> 01:34:07.921 But the simplest case is that at this point, places where
01:34:07.921 --> 01:34:12.700 presently we have to duplicate code or write a lot of code to
01:34:12.700 --> 01:34:15.630 handle what should be the same thing.
01:34:15.960 --> 01:34:20.061 This makes it super easy for us to write it all in one place, so
01:34:20.061 --> 01:34:24.036 just some neat stuff that's come out of some of the recent the
01:34:24.036 --> 01:34:27.884 the recent surge arising that's been done over in in Phoenix
01:34:27.884 --> 01:34:28.200 land.
01:34:30.710 --> 01:34:31.030 Yeah.
01:34:31.040 --> 01:34:33.000 So the settings for this block look like this.
01:34:33.010 --> 01:34:36.704 Basically, where it's going to lead them out of the JSON or and
01:34:36.704 --> 01:34:37.570 all that stuff.
01:34:37.580 --> 01:34:41.140 This all works and I can do like I use it globally.
01:34:41.200 --> 01:34:43.670 So like everything just gets the minimum rate, amount, period.
01:34:43.810 --> 01:34:45.530 It's everything has to be a minimum $25.
01:34:45.540 --> 01:34:45.840 Whatever.
01:34:46.470 --> 01:34:46.970 Umm.
01:34:47.410 --> 01:34:50.064 And then if I don't want to do a global one, I could do more
01:34:50.064 --> 01:34:50.630 specific one.
01:34:50.640 --> 01:34:52.020 So I can say like per ship carrier.
01:34:52.180 --> 01:34:56.104 So like UPS or FedEx, maybe I say UPS the minimum $25 in FedEx
01:34:56.104 --> 01:34:57.350 is a minimum of $20.
01:34:58.090 --> 01:34:58.600 Umm.
01:34:58.840 --> 01:35:03.094 Or he can get even more specific and say for this carrier for
01:35:03.094 --> 01:35:07.279 this rate type of that carrier like ground versus overnight,
01:35:07.279 --> 01:35:11.464 maybe ground is a minimum $10 and overnight has a minimum of
01:35:11.464 --> 01:35:11.670 20.
01:35:12.850 --> 01:35:16.217 For FedEx you can go do all of that stuff in there, and then
01:35:16.217 --> 01:35:19.639 there's a separate one that runs after the minimum rate quote
01:35:19.639 --> 01:35:19.860 one.
01:35:19.870 --> 01:35:22.160 Or if you don't have it, there just doesn't run out at all.
01:35:22.830 --> 01:35:26.241 It does a percentage modifier of your rates, so maybe you just
01:35:26.241 --> 01:35:29.218 want to give it like a 10% uplift, so that all of your
01:35:29.218 --> 01:35:30.680 rates are for sure covered.
01:35:30.690 --> 01:35:33.460 Because by then, if it had extra costs, you've covered it.
01:35:33.530 --> 01:35:33.870 Yeah.
01:35:33.750 --> 01:35:36.307 Or maybe you wanna reduce it because you think one of them is
01:35:33.880 --> 01:35:34.620 So like maybe yeah.
01:35:36.307 --> 01:35:37.050 like, really high.
01:35:37.610 --> 01:35:40.850 You could do a make it 90% of what the original cost was on
01:35:40.850 --> 01:35:44.361 there, and and it's got the same setup where you can do a global
01:35:44.361 --> 01:35:47.709 or you can do like per provider or like a per particular rate
01:35:47.709 --> 01:35:50.949 type of a provider and all the way down in there with these
01:35:50.949 --> 01:35:54.190 modifiers and whatever you don't set basically just says it
01:35:54.190 --> 01:35:55.540 leaves it alone on there.
01:35:58.760 --> 01:36:01.142 So that's kind of the extra stuff that you can run in the
01:36:01.142 --> 01:36:03.770 background and by isolating that code is coming to recreate it.
01:36:03.780 --> 01:36:06.868 Like you said, in all those different providers, we don't
01:36:06.868 --> 01:36:10.063 have it more standardized and more copied there so that the
01:36:10.063 --> 01:36:13.258 provider itself just has to worry about making its own rate
01:36:13.258 --> 01:36:15.920 quotes in and spitting those out to the universe.
01:36:17.290 --> 01:36:21.569 And and I have been trying to work on things like this where
01:36:21.569 --> 01:36:26.058 if the developer provides like really good documentation around
01:36:26.058 --> 01:36:29.986 like example requests and responses, great copy them in
01:36:29.986 --> 01:36:32.020 here, slap them down in here.
01:36:32.150 --> 01:36:34.765 I got the whole JSON file like what they said is their example
01:36:34.765 --> 01:36:36.260 of thing with all this stuff in it.
01:36:36.530 --> 01:36:37.270 They've even got a.
01:36:38.590 --> 01:36:42.680 Uh, whatever it's called the the DTD on one of these files.
01:36:43.070 --> 01:36:46.912 I think I have another spot, but I have that explains what every
01:36:46.912 --> 01:36:50.577 single one of these properties is and does, and then I turned
01:36:50.577 --> 01:36:54.124 to all of that into uh classes and the classes if they have
01:36:54.124 --> 01:36:57.080 properties, have the content of that stuff in it.
01:36:57.170 --> 01:36:58.440 So I have their their examples.
01:36:58.450 --> 01:36:59.450 I have their remarks.
01:36:59.460 --> 01:37:03.169 I have the standard, you know, summary XML stuff that's on them
01:37:03.169 --> 01:37:06.299 and I have like the JSON properties that they convert
01:37:06.299 --> 01:37:10.009 into and I have extra stuff that works with Resharper that says
01:37:10.009 --> 01:37:13.428 this is the accessibility Enum has default values for this
01:37:13.428 --> 01:37:14.240 accessibility.
01:37:14.250 --> 01:37:16.879 One that says that it should normally be one of these two
01:37:16.879 --> 01:37:19.690 values and it will give you that information in your tooltip.
01:37:20.600 --> 01:37:23.310 It is on an actual enum because an enum doesn't make strings.
01:37:23.480 --> 01:37:26.323 These are constants, but it knows that it turns it into
01:37:26.323 --> 01:37:29.470 those things, which makes it really cool to do those lookups.
01:37:30.410 --> 01:37:30.820 Umm.
01:37:30.830 --> 01:37:33.238 And that you should be expecting to be able to either put the
01:37:33.238 --> 01:37:35.724 value into your request or get that or particular value on your
01:37:35.724 --> 01:37:36.890 response and how to handle it.
01:37:36.900 --> 01:37:38.140 You can make a switch case for.
01:37:38.390 --> 01:37:40.895 Well, what happens if I do one of the address to the other or
01:37:40.895 --> 01:37:43.320 whatever is the other one of these I could just switch case
01:37:43.320 --> 01:37:45.744 of all of these and it just knows that all these things are
01:37:45.744 --> 01:37:47.320 linked together, which is really cool.
01:37:48.780 --> 01:37:52.128 Can you, uh, jump over over to the minimum rate amount settings
01:37:52.128 --> 01:37:52.390 file.
01:37:52.400 --> 01:37:54.400 You have it open in your top left window there.
01:37:56.680 --> 01:37:57.080 This one.
01:37:57.700 --> 01:38:01.598 Yeah, this is what this is like the the evolution of what like
01:38:01.598 --> 01:38:04.630 SEF Config dictionary looks like in current SEF.
01:38:04.640 --> 01:38:07.735 This is kind of the similar functionality built out in
01:38:07.735 --> 01:38:11.000 Phoenix, so all you do is you derive from settings space.
01:38:11.010 --> 01:38:14.286 You pass the type of the settings file in, so it's
01:38:14.286 --> 01:38:18.526 another use of the CRTP pattern, but it's that pattern gives us a
01:38:18.526 --> 01:38:20.710 lot of really cool, useful stuff.
01:38:20.720 --> 01:38:24.360 So we've been using it a lot because I think it's cool, but
01:38:24.360 --> 01:38:27.817 there are two methods that setting space class gives you
01:38:27.817 --> 01:38:31.518 read setting and read required setting read required setting
01:38:31.518 --> 01:38:35.279 will throw if it attempts to read it and it's not been set in
01:38:35.279 --> 01:38:37.220 either the JSON or the database.
01:38:37.930 --> 01:38:41.824 Read setting will not throw, it'll just return the default
01:38:41.824 --> 01:38:42.220 value.
01:38:43.010 --> 01:38:45.833 And Speaking of those default values, the default values,
01:38:45.833 --> 01:38:47.780 actually the argument to read settings.
01:38:47.790 --> 01:38:50.570 So it's strongly typed instead of being in an attribute.
01:38:50.580 --> 01:38:53.656 That could be any type, not constrained the type of its
01:38:53.656 --> 01:38:54.150 variable.
01:38:54.430 --> 01:38:58.353 It is, yeah, it's it's strongly typed with the generic argument,
01:38:58.353 --> 01:39:01.793 and obviously as as is the case with all generics, it it
01:39:01.793 --> 01:39:04.690 attempts to match based on what you passing in.
01:39:04.700 --> 01:39:07.780 The only reason we had to specify nullable double online
01:39:07.780 --> 01:39:10.050 19 is obviously because null isn't typed.
01:39:10.060 --> 01:39:14.897 It doesn't know what null is, so you can tell it is a nullable
01:39:14.897 --> 01:39:16.740 double, but this is the.
01:39:16.780 --> 01:39:20.957 You can also do it that way, but this is the umm this sort of
01:39:20.957 --> 01:39:24.864 evolution of self config dictionary with the intent being
01:39:24.864 --> 01:39:28.906 that each of these settings files is relatively concise and
01:39:28.906 --> 01:39:33.083 short and very focused on the specific settings that it deals
01:39:33.083 --> 01:39:33.420 with.
01:39:34.290 --> 01:39:34.910 Umm.
01:39:35.210 --> 01:39:39.436 And so in this case, the minimum like rather than having one big
01:39:39.436 --> 01:39:43.077 giant shipping settings thing where there's a bajillion
01:39:43.077 --> 01:39:46.782 settings in it, all of the settings stuff for or each of
01:39:46.782 --> 01:39:50.878 the settings plugins have their own settings files, and longer
01:39:50.878 --> 01:39:54.519 term, a lot of the intent with that is to automatically
01:39:54.519 --> 01:39:57.380 generate settings UIS based on these files.
01:39:58.290 --> 01:40:02.497 So being able to go in and pick up the settings files from each
01:40:02.497 --> 01:40:06.178 plug in and then have a page in the admin that uh, that
01:40:06.178 --> 01:40:10.254 generates editors for minimum rate amount settings that has a
01:40:10.254 --> 01:40:14.133 check box for booleans and a number field for doubles, and
01:40:14.133 --> 01:40:18.406 you know it's cetera being able to generate forms that allow you
01:40:18.406 --> 01:40:21.430 to edit settings for things in a really cool.
01:40:22.860 --> 01:40:26.983 Clear and concise way instead of having to either manually build
01:40:26.983 --> 01:40:31.107 those forms or lump it all into a single grid like we have it in
01:40:31.107 --> 01:40:33.010 the admin settings editor now.
01:40:33.280 --> 01:40:36.600 So just makes things a lot easier and one of the little
01:40:36.600 --> 01:40:39.920 side things I mentioned in there was database settings.
01:40:40.830 --> 01:40:45.286 So that's to avoid where in some hosting environments modifying
01:40:45.286 --> 01:40:49.602 files on disk is prohibitively tedious, or just can't be done
01:40:49.602 --> 01:40:50.090 at all.
01:40:51.810 --> 01:40:55.935 An example, maybe not impossible to do in Docker, but it's more
01:40:55.935 --> 01:40:59.931 complicated to to go modifying files inside a Docker instance
01:40:59.931 --> 01:41:03.734 and making sure that they persist and so we have still the
01:41:03.734 --> 01:41:07.408 ability to specify certain settings and JSON and some of
01:41:07.408 --> 01:41:11.340 them obviously have to be like a database connection string.
01:41:13.290 --> 01:41:16.443 But then you can specify settings in the database as
01:41:16.443 --> 01:41:19.120 well, which will override the JSON settings.
01:41:19.690 --> 01:41:23.259 UM, and that makes it so that you can specify settings at the
01:41:23.259 --> 01:41:26.541 database level and all it's doing is reading and writing
01:41:26.541 --> 01:41:29.880 from the database as it already does for everything else.
01:41:29.890 --> 01:41:33.106 And we don't to worry about like file manipulation on the disk,
01:41:33.106 --> 01:41:35.970 at least for settings setting, which is very convenient.
01:41:36.800 --> 01:41:40.520 Umm, so some fun stuff there.
01:41:45.160 --> 01:41:48.090 And then this is an example of I'm in the settings.
01:41:48.540 --> 01:41:53.381 I'm building settings that I will use within the tests so
01:41:53.381 --> 01:41:56.470 that the test object gets populated.
01:41:56.480 --> 01:42:00.200 This, as opposed to what's on disk or was in like the clients
01:42:00.200 --> 01:42:03.860 database at the time because I need aesthetic and repeatable
01:42:03.860 --> 01:42:06.080 version of the settings for my test.
01:42:06.800 --> 01:42:10.400 Umm, so I have a one time setup which is a thing that in unit
01:42:10.400 --> 01:42:10.690 does.
01:42:10.930 --> 01:42:14.597 So when this class executes, it will execute this once, bloated
01:42:14.597 --> 01:42:18.207 up at in a memory, and then I have to worry about it again for
01:42:18.207 --> 01:42:18.780 each test.
01:42:18.840 --> 01:42:21.480 There's an alternate version of this that does a regular setup.
01:42:22.110 --> 01:42:25.861 Does not one time and it will run it between each test or
01:42:25.861 --> 01:42:26.960 before each test.
01:42:26.970 --> 01:42:29.550 I should say on it.
01:42:28.400 --> 01:42:32.290 And I believe there's also equivalents for tear down.
01:42:32.380 --> 01:42:34.800 It's like teardown and one time teardown or something like that.
01:42:33.000 --> 01:42:33.180 Yes.
01:42:35.450 --> 01:42:36.410 Yeah, there is.
01:42:36.060 --> 01:42:38.370 Umm so you can clean up or yeah so.
01:42:36.420 --> 01:42:36.810 Tear down.
01:42:36.820 --> 01:42:37.480 One time, Dara down.
01:42:38.130 --> 01:42:39.620 What X unit does for those?
01:42:39.630 --> 01:42:42.333 Is it it expects you to put them into the constructor and
01:42:42.333 --> 01:42:45.409 destructor for anything that you create your own function and you
01:42:45.409 --> 01:42:46.900 put the attribute on it with it.
01:42:46.950 --> 01:42:50.001 So I don't think the name of the function matters, it's just the
01:42:50.001 --> 01:42:51.410 attribute that it cares about.
01:42:51.590 --> 01:42:55.611 So in here what I did was I created a dictionary the same
01:42:55.611 --> 01:43:00.117 way that the under the hood here is for the settings space and I
01:43:00.117 --> 01:43:04.553 populate the keys and values and stuff that I'm going to do for
01:43:04.553 --> 01:43:08.505 my FedEx settings into it with these particular URLs and
01:43:08.505 --> 01:43:10.030 addresses and whatnot.
01:43:10.800 --> 01:43:12.170 Excuse me and I put them in.
01:43:12.180 --> 01:43:16.835 I I force them into the loaded settings right here with test
01:43:16.835 --> 01:43:20.880 mode turned on and it will make it use that instead.
01:43:21.530 --> 01:43:24.840 So by not passing that in on the load settings, which is the
01:43:24.840 --> 01:43:28.313 default for stuff, you would get the regular one and by passing
01:43:28.313 --> 01:43:31.732 it in it forces testing mode on to use that particular setting
01:43:31.732 --> 01:43:35.096 and basically override so that it doesn't try to load it from
01:43:35.096 --> 01:43:38.406 the database or from the, you know, Jason files and whatever
01:43:38.406 --> 01:43:39.600 that it can load from.
01:43:40.350 --> 01:43:41.820 So we simplify some of that stuff.
01:43:41.890 --> 01:43:43.240 So just makes it really quick and easy.
01:43:43.310 --> 01:43:46.569 It looks ugly as sin because that's a lot of characters and
01:43:46.569 --> 01:43:49.827 it's a lot of news and stuff, but it's also really strongly
01:43:49.827 --> 01:43:52.000 typed against your FedEx settings type.
01:43:52.510 --> 01:43:53.780 So I have embedded JSON.
01:43:53.790 --> 01:43:54.820 I have embedded dictionaries.
01:43:54.830 --> 01:43:57.824 I have whatever structure I'm putting into the settings to
01:43:57.824 --> 01:43:58.890 make them make sense.
01:43:59.660 --> 01:44:03.380 I can recreate here and I don't have to worry about mistyping my
01:44:03.380 --> 01:44:06.813 own JSON or something else that's weird, or reconverting it
01:44:06.813 --> 01:44:10.133 might of stuff they're they're just there and they're and
01:44:10.133 --> 01:44:13.738 they're they're with their good, solid, you know, typed values
01:44:13.738 --> 01:44:17.343 and everything, just like the read settings would want them to
01:44:17.343 --> 01:44:19.690 be for that stuff, which is really nice.
01:44:20.940 --> 01:44:24.370 I applied BL4, building this stuff up.
01:44:24.380 --> 01:44:28.349 This way I just went in and tweaked a little bit to add more
01:44:28.349 --> 01:44:29.520 more things to it.
01:44:30.140 --> 01:44:31.790 It's really mostly him on that part.
01:44:33.160 --> 01:44:35.030 Umm, so that kind of stuff, you know?
01:44:35.040 --> 01:44:35.570 Pretty cool.
01:44:35.800 --> 01:44:38.880 We are 10 minutes over, so I would say let's go ahead and
01:44:38.880 --> 01:44:39.730 stop and let go.
01:44:40.620 --> 01:44:43.317 I'm going to go away now and rest my voice because I've been
01:44:43.317 --> 01:44:44.290 talking too damn much.
01:44:45.020 --> 01:44:47.550 Umm, I think we can go ahead and stop the recording as well.
01:44:46.690 --> 01:44:46.920 Umm.
01:44:51.070 --> 01:44:52.130 Or it's already off?
01:44:51.850 --> 01:44:53.720 Yeah, I'm working on it now.