 It's working. Cool. Thank you, friend. All right, my name is Mike Schudy. I'm here to show you very little code, but tell you a whole lot about how I think you should write it and the processes. You should kind of adopt mentally in your workflow. I appreciate you all coming out. I know it's late in the week. But we've learned a lot of like really cool technical topics and different mental frameworks, and it's been super stimulating. So I know physically, mentally, it's a lot. So I appreciate you coming out, even if most of you are here because there was overflow from the sexier webpacker topics. But yeah, let's go ahead and go over the general scope of what we're gonna cover today. I'm gonna go pretty unusually long into my background, but I promise there's a purpose for that. And then we're gonna get kind of normed on our goals for today. I liked the previous talk, talking about the victory conditions. We're gonna take a second to kind of make sure that we're clear on that. Then we're gonna talk a little bit about testing paradigms and kind of the different ways we can go about testing and what I mean by a paradigm in this case. And then we're gonna dive deep into the point of this whole talk, which is how to think of testing as more of a storytelling process and not just an obligation that you have or a potential dopamine hit from a green suite. Then we're gonna do an experimental demo. I'm gonna be looking for some help on that and just to walk through a potential actual process of applying product requirements or different specs into a story that could then be used to implement some actual functionality. And then we will kind of review what we cover, make sure we're walking away with at least one substantive kind of piece of information that will influence us going into the next weeks and months of our work. And we'll be on our way, waiting for the awesome tender love closing keynote. Cool, so we have five, one, four, 20, eight, two. And I was gonna try to show off some fancy proc syntax with Ruby, but then I remembered that it's Ruby and you can just call it dot some. So it's like, thank you, Matt. So I currently live in Detroit. I work for a company called Quickly. It's a digital marketing platform where we get to use really beautifully written rails core. We have some React front ends, some Go services for our high traffic endpoints. Really interesting challenges that we get to solve. My favorite one is we have basically hundreds of thousands of users hitting one endpoint in a matter of five minutes. And that's like really interesting. Sometimes over my head in terms of how we handle that. How I got into coding. I studied environmental science in undergrad and then with the environmental issues I started becoming more and more interested in the social issues. So I ended up tacking on a sociology major. And that led me to serving for a year as a city year core member, which is like a volunteer AmeriCorps program. And I worked with fifth graders in a classroom for a year and that was really an incredible experience. A lot of highs, a lot of lows. That led me to have more of an interest in structural systems. Like how do we end up with education and equality? What are the societal factors that lead to some students having iPads for every student in the room and other students with 20 year old textbooks, right? What are the structural conditions that lead to that? Quickly found out that I cared a lot more about telling people about sociology because I went to grad school, I was in this PhD program, I was gonna be a professor and then I found myself just running regressions on big data models and I missed the kind of fire that the theory and like the awareness that the actual kind of more qualitative stuff brought me. So decided to move back to Denver. I had moved to Indiana, came back to Denver where it was my home at the time and I was just about to get a job at a coffee shop and start writing about education and start maybe pursuing music, just doing the whole gig economy. I had my Lyft certification, everything taken care of and my partner Hannah had heard of a boot camp in Denver called Turing and she wanted to go and get some feelers on what it was like. She was interested in some basic comprehension of HTML, CSS, front end type technologies. I came along for moral support and five minutes in we found out that Turing was looking for 70 hours a week and seven months and full time commitment and Hannah who had a great job quickly became very uninterested and all of a sudden with no programming experience and for no reason other than curiosity I was super intrigued. One thing led to another and all of a sudden I started caring about lining up my equal signs and having skinny controllers and starting to think of equal signs as assignment operators altogether. So the whole nerd life was a pretty robust transition for me. Then I was still able to kind of pursue my loves for long distance running and writing music, piano and guitar and singing all these things that exercised different parts of the brain and I love reading fiction and writing poetry. And I warned you but then of course you're like why is this guy trying to tell me so much about his life? I wanna learn how to test. I wanna learn how to write better tests. So there's a reason for that, right? I gave you a bunch of context for me and context is super important. It's kind of a critical component for the way I'm gonna frame storytelling and how it can help you write better tests. So keep context in mind. Goals for you, this is how I'm gonna frame my success and it's one of those things like as a teacher it's just I will never know if it really worked unless you tweet at me, a team like you where you can also get the slides. That was another, my most recent tweet you can get the slides for these if you wanna follow along. So my goals for you, the things I want you to keep in mind if you start to disagree with something or you start to get confused by something just kind of try to reorient yourself and use these goals as kind of a compass. Like am I on this track? Am I either getting more perspective either enriched or new found perspective on what it means to test? Why we test? How can I test? And also a new found or again like reinforced or newly founded sense of confidence in your ability to write tests. So I know from experience that some people don't end up writing tests because they don't know how to test. They don't feel like they know how to test the right things. And this is silly because in a lot of ways that you have some innate human capacity to write really expressive and like very robust tests that will help you write better software. Cool. So when we talk about testing it could mean a lot of different things. If you're interested in that daily vocabulary buildup just in case. If you haven't run across the adjective form of paradigm we can all of a sudden pronounce the G hardly and say paradigmatic. And in this sense I'm just talking about that testing is paradigmatic because it is kind of surrounded by the certain assumptions that we use and agreed upon methodologies for figuring out how to do it. And these core assumptions and methodologies lead to drastically different outcomes. So a lot of what we're talking about is gonna have like subtle and like nuanced differences. But it's kind of like when you have an angle the origin can be quite similar but as it goes out the consequences and outputs are like very different. So that's kind of something to keep in mind is that the way we think about actually doing this thing can have can make a really big difference. Cool. One testing paradigm is test last and it's basically what it sounds like. You have a somewhat functioning code you've implemented a program or full on application and then you remember you're in the Rails community like I should have some tests. So you write a bunch of tests. Hopefully they pass. That was probably a very hard process to write tests for existing software. And then you have a green test suite and this is you know it's better than nothing I suppose but it has some like some hidden caution some dangers I guess within there because you might have bugs embedded in your implementation and you have kind of false assurance that a green test is saying hey it's all good but all you have is an existing implementation you've designed a test to fit that implementation which is similar like a circular definition by saying blue is blue because it's blue which is a bit puzzling when you think about it. So test last is kind of in one extreme camp where you just kind of tack it on at the end and wipe your hands call it a day. When we step over the main boundary line to a more test first or test driven paradigm we benefit from this great design principle of red-green refactor which means we write the test and we're in the red because we haven't written any codes we are automatically failing. I've basically told a story to my test suite or my interpreters describing certain functionality be it the smallest feature the biggest function and the computer hears this story and it's like yeah but it's not really happening like you're saying this is the case but I don't see it. So you get failures and in rails that whole process is just incredible right? It's like holding your hand down the path for most basic CRUD functionality things like that. So then you finally you walk through those errors you get a passing implementation then you're free to refactor right? The idea is to just follow along address one error at a time stay focused use that test as kind of a guide to get to your overall goal. At that point once you have a passing test you can refactor. Oftentimes those refactors will break the solution you'll have a failing test you implement it again to get green and you have this like kind of hardening phase I think of it like a heading inward on a spiral until you find like the one that you're really happy with the one you'd be happy to pull open a PR on. So test first is a bit misleading because it's more similar to test last in my opinion than to test driven because this process again it's like very nuanced but you're saying okay I have this requirement and I pretty much know how I'm gonna do this. Okay so how would I do this? I'm gonna write the test with this solution in mind and I actually found a lot more clarity on the difference thanks to these ideas introduced at this conference like conceptual compression where you know we want to like kind of compress ideas and store them in like smaller parts or in parts of our brain that we can kind of dig into when we need but otherwise clear up space in our heads and with a test first philosophy you might be writing the test file first but you're clouding your brain with the implementation details and so just like good object oriented programming we want to not be doing multiple jobs at once right? So test first is basically writing a test with the implementation in mind and this limits you from the like really nice benefits of test driven design. So test first this is like taking the leap to hey I'm totally ignorant to how I'm gonna implement this I know that I basically I have this input or I have this user action and I want it to result a return in some side effect or some value and what's really beautiful about this is it frees you up to just think more like a user right? When this thing happens what should be like the grand side effect or the grand return and all of a sudden you're thinking more about what makes sense and what feels good and not just does it work. So that's test driven and behavior driven is this kind of like higher conceptual level where we're not just thinking about does the code work but is it valuable? Like is the code we're writing? Like what value does it provide the business or the organization? And so I almost fall back on this is the difference between testing to an interface versus an implementation. There is at the Derek prior talk on migrations there's a great admission of like gang of four the book that I always quote but have never actually fully read. So this idea that we can program to an interface but not an implementation to me is how I kind of think of the difference between test driven you're just saying like hey this function takes some user model count from zero to one versus like no like if a user creates an account the user count is just incremented by one like it changes by one right and frameworks like our spec give us a much more expressive way to describe system changes and not implementation details which would be okay it starts at zero and ends at one well that's a really that's a one time use case right where the database count is zero and the ends up at one so we it's again it's subtle but we want to get in this mindset of what's the overall functionality why is it valuable and how can it how can we write our tests or our code to satisfy these tests cool. So I told you to stop testing and start storytelling but I've just been talking about testing so I'm sure it's obvious that I really do want you to keep testing I just want you to think about it differently right I want you to think about it as a design tool and as a an empathetic tool that helps you constantly remind yourself of users and what it means to be writing software it's absolutely critical that we remember that software is always means to an end always like no matter how fun writing in Ruby is and writing tests and the workflow and it's fun to get good at keyboard shortcuts and all this stuff I love that too but at the end of the day if people if it doesn't make sense to people and they don't feel good and they don't feel confident and they don't feel empowered by the stuff we're making it doesn't matter so the whole point of this is to exercise more parts of our human brains that make us think more like users and have more empathy right because the code you write is gonna influence someone's emotions right and even if it's a database migration right like this is gonna have a cascading effect on the API that we can work with within the app and that's eventually gonna end up whether it's an API or full on full stack app people are gonna interact with the code that you've written in some way and feel good or bad about it so that's like such a responsibility for us to have and so the more that our storytelling and our testing process represents the user and we're kind of writing code on behalf of the user the better software we're gonna write so from function to feature I'll keep kinda using that term like it doesn't matter even if it's just this little helper that you're working on every little algorithm you've written for an app that ends up being used by a user that matters right so it doesn't matter the scope of what you're working on thinking of the user is totally paramount to everything we do so I'm breaking this down into four main topics in terms of how is storytelling similar to writing code and writing software and how can it help us? I'm gonna deviate from these minute expectations because they're fun and they're just yeah I try to hold to them but forgive me if I go over so we have communication, context, abstraction and encapsulation and it's like wow those last two are object oriented principles and it's like yeah it's gonna help us so we're gonna like wed these things we've learned to be good programmers and we already have these existing storyteller and like communicative skills that we have as humans by default so that's really great in a lot of ways we're like our own Rails framework where we just have a bunch of stuff for free so when I think of communication like right now I'm communicating to you it's pretty one way thank you for participating I'm trying to get an idea that's in my head into your head and try to establish some semblance of agreement on what that idea is right and if it goes well y'all like subtweet me or whatever then the idea that I had I can tell is like out in the world and that's comfortable for me right like not even comfortable but it feels nice so when the opposite happens and I have an expectation in my head that doesn't become real that feels really bad we've all had maybe travel troubles coming to conferences things like that you're at the airport ticket gate and your flight's canceled the agent's telling you there's nothing nothing that can be done and in your head you're like I'm like a beautiful butterfly I'm unique and this is my life that's impacted can't you like do something for me and they're looking at you like I have 100 people in the same boat right so what you have is just a conflict or you have disagreement of ideas and heads right like the person who is the airport user is saying I should be treated specially I should have a solution provided and that's not being met right so that feels bad so communication is about good communication is about finding shared agreement on what we're expecting to happen so in that sense users are communicating with software you open your app you have expectations about when you click this button or go to this link I expect certain things to happen and when we have buggy software that has unexpected behavior that's confusing because the world as the user knows it becomes less predictable and that feels really shitty so how do we imbue this whole this entire philosophy of thinking about communication as this like agreement of ideas and providing predictability and comfort we have to think of it as the software we write is ultimately a listener it's listening to what the user does and so we want to when we're writing tests we're basically describing hey the user's gonna I would wanna do this as a user this is what the user's gonna do so I need you to listen to this behavior and do these things when it happens right so when we remove ourselves from the nitty gritty implementation details that require a lot more mental horsepower and we can just say hey how should this flow like what makes sense we're really representing our users and we're gonna end up writing more intuitive cleaner software both on the internals right for our future developers fellow collaborators and for the end users that end up using the finished product the next bit is context I mentioned I was like wow this guy's talking for five minutes about himself at a technical talk with each bit of information you learned a little bit more about me and everything henceforth becomes a little bit more predictable right so it's nice to get to know people because your surroundings become more familiar there might be a case where I don't know we I'm at the bus station later today and we run into each other and you're like oh like I know these things about like your environment all the sudden becomes more familiar, more predictable and more comfortable context essentially provides awareness about how causes and effects are related to each other and how systems work overall and for whatever reason like I have not died into the like academic psychology of why this makes us feel comfortable but there's something about stability and order and just having things like unfold as we expect that makes us feel good so context helps us kind of zoom out and see oh so if this happens then that'll happen and because he's from Denver he probably likes the mountains right so it allows you to create reliable predictions about how the world is and we like this so context brings more understanding just the more that you can see the system that you're looking at or the relationship between causes and effects that's gonna make you understand how future manipulations to the system what types of consequences those will have with more understanding gives you more predictive power you basically have a bigger data set to rely upon to handle ambiguity well I've seen a whole lot of similar things like this so even though I haven't seen this exact case before I can reasonably expect a certain output and I'm speaking in very abstract terms because it's something we do all the time so I encourage you to think about as you navigate new situations meeting new people, being in new cities what are the mental processes you're going through to feel better and feel more at home so more predictive power gives you more confident decision making if I can more easily anticipate changes to the system and be like okay I really know what's going on here like I know everyone in the room I know where the restaurants are okay I know that there are a ton of good restaurants on this street so I feel confident in choosing a place for dinner for the whole group that's not gonna be terrible and give me a bad reputation for picking terrible restaurants that happened to me yesterday and with more confident decision making that's like kind of a no brainer it just feels good right I it's great to feel confident I think of that the idea of building software to make your users feel like a badass right I'm forgetting the author off the top of my head but look into the idea of making your users feel like badass is feeling empowered feeling like they are competent and good at stuff this is really important so all this is to say when we can tell stories about our software we will write better software so I told you about how when I'm telling you about my life you have more context through who I am when you as a developer take the time to zoom out and just think about okay what am I really trying to affect here in the code base what am I really trying to implement you're automatically moving yourself into a space that's contextual within the app not just adding a new feature but how does this feature relate to other features or how does this function relate to other functions and you're occupying a mental space that's gonna be much more aware of how these systems interrelate and what might introduce new bugs and like does the overall implementation make sense like should users be able to do X if Y is like true or what you know you can recognize these relationships with a lot more ease and intuition as opposed to when you're deep in writing a reduce function like you're getting lost on which one's the accumulator and which you know whatever so context as a developer you can find more context when you take this storytelling mindset when you're writing your tests because you're paying attention to how does this individual part this method or feature under test that I'm looking at how does it relate to other things and how does it ultimately make sense to users cool so we have communication we have context and now we're getting into the interesting bit of saying well yeah abstraction and encapsulation those are principles of object oriented programming they're also principles of how we go throughout day to day life right these are principles I would say of storytelling as well so we're gonna go through some built in Rails magic that our bodies have you touch a stove right you say oh that's hot let me send a little worker job up to my brain signal like hey we have some heat on the hand send back down some instructions on how to move my fingers and then do like a oh shit method right no right we have these like automatic processes that produce some change in state some change in output some side effect that's really cool right we take advantage of abstractions all the time so while they seem intimidating sometimes and this is a word that's come up a lot right like should we lean on abstractions should we dig into them should we understand everything I think there's a lot of proof in the pudding that we the things that we are able to do are enabled by abstractions right like if I had to worry about how to actually implement movement and not just think a movement and have movement then I wouldn't be able to do very much so that's a case where abstraction really does open you up to do more advanced or innovative things breathing is another one I have some agreement some internal contract where I'm agreeing to stay on this interval and if I interfere with that public API of continuous breathing there's gonna be some like undefined errors going on and people are like the collaborating objects are gonna be freaking out so that's another thing right breathing it's abstracted away we don't know the implementation details we figured them out because we're humans and we love figuring stuff out but I don't have to know how I just need to interface well with the API of breathing muscle memory if you type on your computer most days you probably get better at typing you may not even have to look anymore this allows you to just think of words and have them on the screen you don't have to look down where's the back tick okay that one that one took me a while to learn back ticks and all of a sudden they're just appearing on the screen and so there's one hurdle removed between the program you want to write or the test you want to write and the reality that's represented on the screen muscle memory another great example of abstraction that we experience on a day to day basis that enables us to do more complex tasks with ease also literally every spoken written body language ever is abstraction right everything I'm doing and saying and representing as symbols up on the screen they don't have inherent meaning we've learned to associate them with real world objects or other abstract ideas and we are able to leverage abstractions to communicate more complex or bigger topics by compressing them like a word is a great example of conceptual compression right I can refer to a stove and not have to explain to you what a stove is how it's used what are the parts right we just have these abstractions that are made up of sounds and visuals that help us have it like a shared agreement on what I'm talking about shared understanding so abstraction is awesome you are good at it super good at it like probably one of the best in the on earth there might be better in the great beyond but this is something that like you can really recognize in your everyday life and it's something that again the whole point of it is to enable us to do more advanced tasks be able to think more clearly and kind of compartmentalize different jobs that we have as programmers which brings us into encapsulation we have these principles that guide how we write code and sometimes I think we forget to actually apply those to our own thought processes right when class has too many jobs we call that a code sniff right when a person has too many jobs we kind of well in some cases we glorify it right there's kind of the kind of kind of a double standard and so if we find peace and happiness and single responsibility in our code and you know I know that doesn't hold water all the way through but I think there is something to be learned from the fact that when we're programming we are constraining our imagination we're constraining our clarity of thought because we're limited by the constructs of the language we're working in if you whenever you're talking to someone about software it's a lot easier especially you know and like product people are I'm showing my mom some app and she's like oh it'd be cool if you could do this she's not worried about if it's possible right she just has she has an idea and she's like I think you know if you could click here then this would show up and so we think of a lot better ideas we think in more fluid ways when we're not trying to think of as both programmer and user so maybe we should separate those more clearly separate concerns temporarily right we have we're not a literal class we can be dynamic but I can maybe put my programmer hat on when I need to implement code and I can put on my user my storyteller hat on when I need to describe how the software should work cool when you are writing tests you should think about once I get into implementing and I get really stuck on something I don't know how I'm gonna do this yet I'm gonna get confused by some third-party documentation or how a method works or how to like instantiate a job instance think about your tests is where you're gonna come back to kind of reorient your compass back home you have some ultimate goal and more often than not you're gonna run into some snags and one great way to keep that story like keep that whole big picture in mind of like your whole purpose about what you're working on is to have a really expressive and like kind of human human story oriented compass that can help you get back on track I don't know about you but oftentimes when I get deep into a bug at the end of the day I just wanna go home but I feel bad because I'm like wait what did I just get stuck on okay I got stuck on this what was I ultimately trying to do and then I can keep zooming out and I try to remind myself okay and that's gonna let users log in easier with SMS like okay that was time well spent it felt like mental spaghetti but I'm feeling I'll get it tomorrow and that's okay so all of this kinda led me to as I was preparing this talk this kind of like meta fractal alert and this is I love programming cause I think there's so many lessons we can learn about how we think cause it's ultimately like structured decision making that lead to outputs so programs solve problems right in general programs solve problems I think that's mostly a fact or they make more problems but they're involved they're involved in problem solving the process of writing programs is a problem solving process so our problem as developers is to write things make things that solve problems so we're problem solving to make problem solvers so it's like whoa inception the streets are folding in on themselves so this is all to say that like hey if these principles help us write better programs maybe those same principles we can use on our own process to be better programmers so just by approaching our process with more discipline and more intention separating concerns when I'm writing a test I should be basically separating the logic and the data from just like how should it work so my implementation is what's gonna actually make it so but I can occupy this responsibility of just describing how the software works when I'm writing my test so to wrap up all that Uncle Walt Whitman would say that we contain multitudes right like there are so many perspectives and thoughts and opinions and expectations that we represent at any given time and two of those that are most important in our day to day work is the two hats of user and programmer so when you are implementing code you're thinking like a programmer and you're not really thinking about how does this filter function or how does this active record relation really affect my user and that's okay I don't think you should be thinking about the user when you're implementing code I think you should be thinking about the user in your testing suite and this is why I think it's a design issue it's not about having that dopamine hit and that sense of like clap for me, pat on the back for being a good Rails developer it really influences the way that you write software so if we start with tests and we think about users it's gonna influence how we design our ultimate programs so here is the experiment I'm gonna ask for your help we're gonna take like five minutes basically to take a crowd source like someone has an issue for a feature or a function coming up so I'm asking for a brave volunteer to just kinda shout out or like raise your hand and then I'll try to just like do a demo kind of pseudo coding our spec to say like hey let's take that idea let's turn it into a test or something that looks like a test and just to like keep that user in mind so please, any takers upcoming issue, upcoming functions something like first thing you have to do after this talk or when you get back to work I knew this might happen that's why I was an experiment okay, this was a funny issue for me because I thought about having pre-made code but the whole point is that I didn't wanna have existing code because then I already have the implementation in mind like I wanted it to be live so in the absence of the volunteered idea which I know, no judgment, I totally understand maybe I could have tweeted about it to like bring an idea I just encourage you to like the next time when you get an issue, when you get back to work just ask yourself okay like how does this request fit into the larger context of my application why is this worth building you might even find that like this actually doesn't sound that useful has this been verified like who wants this and it's like some pet project that some marketer has and you're like okay well love the work you do but I don't know if this really makes sense in our context, right so that's my, we're turning the demo to a call to action all right so what do we talk about we talked about how testing is paradigmatic in the sense that it's governed by some kind of agreed upon principles that lead to accepted or unaccepted methodologies for discovering new ideas and that by choosing different paradigms we talked about test last, test first test driven and then ultimately behavior driven these things will influence our end results, right so by choosing and agreeing upon the way that we're gonna think about the process and the intent of these systems this system in this case would be the process of writing tests for software the way that we agree upon doing that is going to directly affect the end result communication in the context of writing tests and telling stories is about building good listeners turning our software into good listeners thinking about what the user is most likely going to be expecting and in best cases we've maybe done some market research we've interviewed users and we know what they're expecting and we wanna build software that listens well and says, hey, I hear you, I see you I know what you want from me and here you go, here's this great load here's this really intuitive photo interface whatever you're working on the other thing that storytelling and that hat that you can wear gives you is just more context which when you're writing a test you're gonna be thinking more about the integration of the function to the feature and how it collaborates with other parts of your app and you're gonna feel better about implementing new stuff because you're viewing it from a further distance and you're thinking about how manipulations to the system will make certain consequences and result in different outcomes so you're gonna feel better because you are thinking about the broader view and not just focusing in isolation on one bit and then being like, okay, this bit works I don't really know if anything else is gonna break cause there's no other tests I'm just gonna ship it so starting with tests is gonna put you in a different headspace to think holistically to think about the flow of an application and again that software is always means to an end to help users we talked about abstraction you're super good at it you are enabled to do great things by a ton of abstractions that you, we talked mostly about physical examples but even like language these things enable us to do more advanced things and the more that we can build abstractions that hold water and are super good and super solid then we can do more interesting things and then lastly we talked about encapsulation and how applying the same discipline that we might to our code could introduce a much cleaner, more disciplined process that leads to better software so and I don't think it's limited to abstraction and encapsulation right the next time you're reading an article about a design pattern or some type of solution to an interesting technical problem try to like zoom out and be like what is this ultimately doing and could I apply that to my workflow like is there some common knowledge that would make sense there but it's not always gonna be there but I think it's something worth noting that since programs solve problems and we write programs then the principles that we use to guide good software might help us with a better process ultimately the whole point that I really care about this issue and the thing I want you to keep in mind is that thinking of testing as this kind of separate domain of headspace that keeps you closer to your users because you're thinking about how is this ultimately used and why is it valuable and does it make sense so the action plan is to develop kind of a pendulum workflow where you write the test right but we still have to eventually write some code that works and so it's just getting into that rhythm of describing what you should be working on what should ultimately be the output of your effort getting into it putting in the effort producing the thing building the thing that's why we love this job is to put something out in the world but always be conscious of coming back to it right does this make sense okay cool let me come back got a little lost am I still on the right track cool come back we don't want to do like the really long wavelength between the two right where it's like well I'm just gonna like write a big test and then I'm gonna implement a whole bunch of features and just kind of rely on that one test like always come back to it even if tests are passing always remind yourself what was the whole point of this so I hope that you're walking away with a sense of confidence excitement perspective on testing it's it can really be kind of a holistic kind of paradigm shift on how you write code it certainly has for me and yeah I hope you feel empowered and excited to come back to work either tomorrow later today next week and keep your users in mind and tell great stories about your software thank you