Defining a Unit3:34 with Craig Dennis
What exactly is this unit we are testing?
There are different types of automated tested and 0:00 as I originally stated we're gonna be focusing on unit testing. 0:02 So that of course probably triggered you to ask the question, 0:07 well what's this unit that's being tested? 0:09 I'm glad you asked. 0:13 A unit in this case is unfortunately one of those self contained definitions. 0:15 The most definition used is this. 0:18 Unit. 0:22 The smallest testable part of an application. 0:22 That's not a very satisfying answer, is it? 0:25 I mean sometimes this is clear, but often times it's not. 0:27 This lack of a proper definition definitely causes some confusion and, 0:31 of course, arguments amongst developers. 0:35 So how do you locate the smallest testable part? 0:39 Well, a pretty straightforward logical approach to finding 0:42 units in your application is to look at every publicly available method. 0:45 In fact, most IDEs actually will do this for you. 0:50 This is what they do when you create a test from a template. 0:53 They'll build a single test for each method. 0:57 However, this is one of those places where we developers have yet to be replaced. 1:00 The code generation here doesn't actually understand our code, does it? 1:06 It doesn't understand what it is that out code actually trying 1:09 to accomplish, but we do. 1:12 So here's the thing, let's define our unit test as testing a unit of work. 1:15 Now a unit of work is something that causes publicly exposed 1:21 behavior to occur for users of our code. 1:25 Typically, you can gather the units of work by looking at the public facing API. 1:29 An API, or Application Programming Interface, 1:34 is the methods that have been publicly exposed to users of your code. 1:37 Remember that when we declare methods public 1:43 we're defining how we want those users to interact with our objects. 1:45 And the beauty of that encapsulation is this. 1:49 As long as the results are the same from each method, 1:52 we're free to change the implementation however we want. 1:55 Specifically, how we perform the requested behavior when the method is called. 1:58 We might change the implementation by making the code cleaner. 2:03 Maybe we'll make it faster, or have it use other existing code. 2:06 But the point is this. 2:10 The only guarantee to users of your code 2:11 is that publicly exposed behavior will behave as you expect it will. 2:14 And that's all we're really after, right? 2:20 We want to find the publicly exposed behavior or units of work and 2:22 ensure that it does indeed work the way that we intended. 2:26 Whether that be a return value or an internal state change or 2:29 even that misusing it causes an expected exception. 2:33 So if we're only dealing with the public facing behavior, 2:37 how do we ensure that all the private, magical code we have works? 2:41 You know, we don't want to break the DRY practice, so 2:46 we want to make reusable functions. 2:48 And also, sometimes we don't want to expose the inner-workings of our object. 2:51 So surely, there must be some way to work around this, right? 2:55 Well, there is a better way. 2:59 And in fact, just thinking about how to tackle testing public behavior, 3:00 is gonna do just like I said earlier. 3:04 It's gonna make us code better. 3:06 It's going to drive home important programming concepts. 3:08 Testing will help you code in a more professional manner. 3:12 So, in order to get us there, 3:16 it'll help us to have a more concrete example to work with. 3:18 Thinking about programing in the abstract can sometimes feel overwhelming, and 3:21 sometimes you just need to dive in. 3:25 After a quick exercise let's do just that. 3:27 Let's jump into the project for this course, 3:29 which will help us explore these new concepts. 3:32
You need to sign up for Treehouse in order to download course files.Sign up