1 00:00:00,040 --> 00:00:02,920 Hey, a quick message for those of you who are listening to this 2 00:00:02,920 --> 00:00:06,280 episode on Spotify. I have a small favor to ask. 3 00:00:06,640 --> 00:00:10,040 Spotify now allows mobile users to rate podcasts. 4 00:00:10,360 --> 00:00:13,680 I would really appreciate it if you can take a quick pause to go 5 00:00:13,680 --> 00:00:16,120 to the Technically Journal podcast page and leave your 6 00:00:16,120 --> 00:00:18,600 favorite show your best rating on Spotify. 7 00:00:19,160 --> 00:00:21,720 It will help me a lot to get this podcast to reach more 8 00:00:21,720 --> 00:00:24,120 people on the platform. Thanks a lot. 9 00:00:26,720 --> 00:00:29,480 Which is a good segue for us to start talking about your book 10 00:00:29,480 --> 00:00:33,160 Effective Software Testing. I think one key sentence that I 11 00:00:33,160 --> 00:00:36,080 pick when I read your book is that you mentioned to be an 12 00:00:36,080 --> 00:00:39,520 effective developer, you must become an effective software 13 00:00:39,520 --> 00:00:41,080 tester. But in practical world, 14 00:00:41,080 --> 00:00:43,880 sometimes developer and tester, they are two different roles. 15 00:00:43,880 --> 00:00:46,960 So tell us more about this. Why do you say that to become an 16 00:00:46,960 --> 00:00:49,800 effective software developer, you need to become an effective 17 00:00:49,800 --> 00:00:52,160 software tester? Thanks for the question. 18 00:00:52,360 --> 00:00:55,240 I think it's because as a developer, it's your 19 00:00:55,240 --> 00:00:59,000 responsibility to make sure that what you do works, and the only 20 00:00:59,000 --> 00:01:02,480 way to do this is by writing tests that prove to you and to 21 00:01:02,480 --> 00:01:06,680 your team that your code works. So indeed, before and I even 22 00:01:06,680 --> 00:01:09,120 worked in environments like this where I would just focus on 23 00:01:09,120 --> 00:01:12,240 coding and then I would send my software to another company. 24 00:01:12,240 --> 00:01:15,080 This company would do the testing for me, they would send 25 00:01:15,080 --> 00:01:17,440 me a report, they would fix the bug, so on and so forth. 26 00:01:17,840 --> 00:01:21,040 And that's just not productive. Back and forth between these two 27 00:01:21,040 --> 00:01:24,200 teams is too big. And I think, again, it's our 28 00:01:24,200 --> 00:01:26,040 responsibility to make sure that things work. 29 00:01:26,040 --> 00:01:29,520 And automated testing is just such an easy and cheap way of 30 00:01:29,520 --> 00:01:31,840 doing it. And that's why I say in the book 31 00:01:31,840 --> 00:01:34,640 that effective developer is someone that effectively tests 32 00:01:34,640 --> 00:01:38,000 what they do, right? And I think, I mean, I don't 33 00:01:38,000 --> 00:01:39,480 know, I was a developer last time. 34 00:01:39,480 --> 00:01:42,920 Sometimes developers can be very confident type of person, right? 35 00:01:42,920 --> 00:01:46,800 So we rewrite the code, we test a little bit during the local 36 00:01:46,800 --> 00:01:49,400 development, we think it works. We always think it works. 37 00:01:49,600 --> 00:01:52,200 Many developers probably do not enjoy writing tests for some 38 00:01:52,200 --> 00:01:55,120 reasons, maybe apart from unit test sometimes because it's very 39 00:01:55,120 --> 00:01:59,360 close to their workflow. So how would you actually invite 40 00:01:59,360 --> 00:02:02,880 more software developers to actually have more passion or 41 00:02:02,880 --> 00:02:05,440 energy to start writing tests? If they have the perception 42 00:02:05,440 --> 00:02:08,240 that, yeah, I'm super confident of my code, I don't want to 43 00:02:08,240 --> 00:02:10,520 spend more time to write automated tests and things like 44 00:02:10,520 --> 00:02:13,040 that, yeah, that's a very interesting question. 45 00:02:13,320 --> 00:02:16,440 So the first part was you mentioned about developers being 46 00:02:16,440 --> 00:02:18,760 confident, right. And what I always say is you 47 00:02:18,760 --> 00:02:20,960 never know. You don't know how many times a 48 00:02:20,960 --> 00:02:23,640 day you make a mistake. So you program something wrong. 49 00:02:23,720 --> 00:02:25,680 And you only know this once you have tests. 50 00:02:25,720 --> 00:02:28,000 Because if you don't have tests, everything that you code looks 51 00:02:28,000 --> 00:02:29,680 perfect, right? You just believe it works. 52 00:02:29,680 --> 00:02:31,760 As soon as you have tests, then you see, you know, Oh my God, 53 00:02:31,760 --> 00:02:33,880 I'm breaking my tests 50 times a day. 54 00:02:34,160 --> 00:02:36,920 And then you quickly realize how much you need them because we 55 00:02:36,920 --> 00:02:40,040 break stuff all the time. Now, how to convince developers 56 00:02:40,040 --> 00:02:42,680 to write tests? That's a very deep question. 57 00:02:42,680 --> 00:02:44,040 I think there are many angles to this. 58 00:02:44,040 --> 00:02:47,400 One is to show to them and to have them practice so that they 59 00:02:47,400 --> 00:02:50,080 don't see writing tests as something that is a burden. 60 00:02:50,120 --> 00:02:52,880 They just get used to it. They get proficient with writing 61 00:02:52,880 --> 00:02:56,280 tests, not only with the testing frameworks, but on writing code 62 00:02:56,280 --> 00:02:59,280 that is easy to be tested on. You look at a program and the 63 00:02:59,280 --> 00:03:02,000 test cases emerge in your head, and all you need to do is to 64 00:03:02,000 --> 00:03:03,800 code them in your programming language. 65 00:03:04,000 --> 00:03:07,000 So there's this aspect of just practicing and getting better at 66 00:03:07,000 --> 00:03:10,000 tests itself. The second one, if you are in a 67 00:03:10,000 --> 00:03:13,240 very large and complex software system, things are too complex, 68 00:03:13,640 --> 00:03:15,360 right? And then for you to have this 69 00:03:15,360 --> 00:03:18,400 pleasure back in writing tests, you need to make sure it's easy 70 00:03:18,480 --> 00:03:21,240 to write tests. And this means as a company or 71 00:03:21,240 --> 00:03:24,480 as a team, you have to invest in a small infrastructure that 72 00:03:24,480 --> 00:03:27,120 facilitates the act of writing tests. 73 00:03:27,480 --> 00:03:30,480 I was discussing this yesterday, actually, not here at the 74 00:03:30,480 --> 00:03:32,800 company, but in another university that I was yesterday. 75 00:03:32,800 --> 00:03:34,640 And I was saying, if you're working on a very complex 76 00:03:34,640 --> 00:03:36,800 software system, to test something, maybe you need to 77 00:03:36,800 --> 00:03:41,920 know to instantiate 10 entities or have data in 30 different 78 00:03:41,920 --> 00:03:43,920 tables in your database. And that's just because your 79 00:03:43,960 --> 00:03:47,400 business is complex and you have to have some something in there 80 00:03:47,400 --> 00:03:50,520 that makes this easy for you That in a bunch of couple lines 81 00:03:50,520 --> 00:03:53,800 of code you can set up the scenario you want to test and 82 00:03:53,800 --> 00:03:56,360 then you can do the test. So those are the two 83 00:03:56,360 --> 00:03:58,920 perspectives I see. One is again getting good at 84 00:03:59,080 --> 00:04:01,600 testing itself and the second one is having the proper 85 00:04:01,800 --> 00:04:03,920 platform so that you can write the tests. 86 00:04:04,840 --> 00:04:08,000 Totally makes sense for me. So from my point of view also 87 00:04:08,000 --> 00:04:11,000 sometimes we also need to maybe introduce back like what you 88 00:04:11,000 --> 00:04:12,480 mentioned in the beginning, the pride, right? 89 00:04:12,480 --> 00:04:15,840 So how can you tell that your code works now and also in the 90 00:04:15,840 --> 00:04:18,360 future? There's no other way to do it 91 00:04:18,399 --> 00:04:21,120 other than having some automated tests that can actually prove 92 00:04:21,120 --> 00:04:24,520 that your work is always past, right in terms of test cases. 93 00:04:24,960 --> 00:04:27,960 And I think many developers also think probably writing more code 94 00:04:27,960 --> 00:04:29,520 means like doubling their effort, right. 95 00:04:29,520 --> 00:04:32,240 So I think this must be changed as well in terms of perspective, 96 00:04:32,320 --> 00:04:35,440 so that you don't finish writing the code if you don't have the 97 00:04:35,440 --> 00:04:37,600 test. Maybe just some perspective from 98 00:04:37,600 --> 00:04:40,520 me, Let's move to the thing that you mentioned in the book, 99 00:04:40,520 --> 00:04:41,960 right. So will you mention about 100 00:04:41,960 --> 00:04:43,880 effective? And there's another keyword that 101 00:04:43,880 --> 00:04:46,200 actually you mentioned in the book which is systematic. 102 00:04:46,600 --> 00:04:49,000 So I find these two things are very interesting the way you 103 00:04:49,040 --> 00:04:50,560 explain in the book. Maybe if you can. 104 00:04:50,560 --> 00:04:54,400 Explain here as well what will be your advice for people to be 105 00:04:54,440 --> 00:04:56,640 a more effective software tester and also to be. 106 00:04:56,640 --> 00:04:58,960 Systematic. In coming up with those tests, 107 00:04:59,680 --> 00:05:01,920 yeah, indeed. So they make a very strong point 108 00:05:01,920 --> 00:05:04,560 that maybe you can be a little bit more systematic when we 109 00:05:04,560 --> 00:05:07,640 approach testing. We wrote a paper a couple of 110 00:05:07,640 --> 00:05:11,640 years ago, and in this paper we asked developers to write tests. 111 00:05:11,640 --> 00:05:15,600 So we gave them a program and write tests, and we observed 112 00:05:15,600 --> 00:05:17,960 them and they were thinking aloud so that we could see how 113 00:05:17,960 --> 00:05:19,640 they were coming up with test cases. 114 00:05:19,960 --> 00:05:21,640 And we observed a couple of things. 115 00:05:21,920 --> 00:05:24,080 Maybe the most important one for this conversation is the 116 00:05:24,080 --> 00:05:26,520 developers were never systematic. 117 00:05:27,080 --> 00:05:29,040 They were always, you know, just following their hearts. 118 00:05:29,040 --> 00:05:31,800 They would look at the code. This feels like the next thing I 119 00:05:31,800 --> 00:05:34,240 want to test, they would go and they would write the test and 120 00:05:34,240 --> 00:05:36,880 then they would repeat what is the next thing I want to test. 121 00:05:37,080 --> 00:05:39,600 So they would just follow their hearts and follow your 122 00:05:39,600 --> 00:05:42,080 experience. And feelings are very important 123 00:05:42,080 --> 00:05:45,080 when it comes to testing, but it also opens up space for 124 00:05:45,080 --> 00:05:47,720 mistakes. Maybe you're not in a good day 125 00:05:47,960 --> 00:05:51,520 and then you forget something. 2nd, if you're always using all 126 00:05:51,520 --> 00:05:55,400 your brain power to come up with test cases, even the basic ones, 127 00:05:55,520 --> 00:05:58,480 you're not saving energy to think of complex cases. 128 00:05:58,720 --> 00:06:01,880 So when you're more systematic in terms of testing, that means 129 00:06:02,080 --> 00:06:04,680 you know you just follow some sort of cake recipe that helps 130 00:06:04,680 --> 00:06:07,360 you to come up with a bunch of test cases that are quite easy 131 00:06:07,360 --> 00:06:09,000 to see. You can put them on a checklist 132 00:06:09,000 --> 00:06:12,000 basically, and then it is your brain power to focus on test 133 00:06:12,000 --> 00:06:14,640 cases. That really requires human smart 134 00:06:14,640 --> 00:06:17,280 people thinking about it. And the fun part is there are 135 00:06:17,280 --> 00:06:20,360 lots of techniques like this If you look at academic books on 136 00:06:20,360 --> 00:06:22,200 testing, even the books from the 80s. 137 00:06:22,360 --> 00:06:24,920 Bigger goal back then was to come up with a recipe that 138 00:06:24,920 --> 00:06:28,320 teaches you how to write perfect tests, and there are lots of 139 00:06:28,320 --> 00:06:30,440 good ideas there and you can think of. 140 00:06:30,440 --> 00:06:32,680 I'm not going to give a tutorial here, of course, but you can 141 00:06:32,680 --> 00:06:35,680 think of basic things like, for example, if your method receives 142 00:06:35,680 --> 00:06:39,080 a list as an input, there are a bunch of interesting cases that 143 00:06:39,080 --> 00:06:40,920 always makes sense. So for example, what happens if 144 00:06:40,920 --> 00:06:43,840 the list is empty? What happens if the list is new? 145 00:06:44,200 --> 00:06:46,600 If there's no linear programming language, what happens if the 146 00:06:46,600 --> 00:06:48,120 list has just one element, right? 147 00:06:48,120 --> 00:06:51,400 Because sometimes your algorithm changes if there are multiple 148 00:06:51,400 --> 00:06:54,440 elements or just one. So there are a couple of basic 149 00:06:54,440 --> 00:06:57,240 stuff that you don't even have to think and you can write those 150 00:06:57,240 --> 00:07:00,120 tests and they are usually good enough to get you to a very high 151 00:07:00,120 --> 00:07:03,080 coverage already and then leaving space for you to then 152 00:07:03,080 --> 00:07:06,480 focus on boundary testing, you know, corner cases and this type 153 00:07:06,480 --> 00:07:08,480 of stuff. And being systematic is 154 00:07:08,680 --> 00:07:11,640 something that you see in other engineering fields, right. 155 00:07:11,640 --> 00:07:14,320 And I think I cited in my book, there's this very famous book 156 00:07:14,320 --> 00:07:17,640 called The Checklist Manifesto. And there's a story there backed 157 00:07:17,640 --> 00:07:21,200 up by research that shows that medical doctors that use a 158 00:07:21,200 --> 00:07:24,800 checklist before some surgery, they make less mistakes that 159 00:07:24,800 --> 00:07:27,960 medical doctors that don't. And you don't have to be ashamed 160 00:07:28,000 --> 00:07:29,920 of following a checklist. It's goods. 161 00:07:30,560 --> 00:07:33,080 And I think that's the point of my book when I say we can be a 162 00:07:33,080 --> 00:07:35,440 little bit more systematic. Of course we don't have to be 163 00:07:35,440 --> 00:07:38,240 systematic all the time. It's just too expensive, maybe 164 00:07:38,240 --> 00:07:40,280 too complex to be systematic all the time. 165 00:07:40,520 --> 00:07:43,080 But identify, you know, like I'm testing a complex method here, 166 00:07:43,080 --> 00:07:44,680 let me be a little bit more systematic. 167 00:07:44,800 --> 00:07:47,240 So that's the whole idea of being systematic when it comes 168 00:07:47,240 --> 00:07:49,320 to testing. Yeah, I think your point is 169 00:07:49,320 --> 00:07:51,440 right. Sometimes we have typical use 170 00:07:51,440 --> 00:07:54,920 cases, just like list or maybe you'll have an API, failure 171 00:07:54,920 --> 00:07:58,200 cases, success cases. So all this can be made as a 172 00:07:58,200 --> 00:07:59,760 checklist. I've heard about Checklist 173 00:07:59,760 --> 00:08:01,840 Manifesto as well. I think the author named Atul 174 00:08:01,840 --> 00:08:04,280 Gawande. And I think becoming systematic 175 00:08:04,280 --> 00:08:07,280 in solving this kind of a testing problem is really 176 00:08:07,280 --> 00:08:09,760 crucial because in your book you mentioned that if you are 177 00:08:09,760 --> 00:08:12,720 systematic, you can assign any developers to the same problem. 178 00:08:12,880 --> 00:08:15,440 They will most likely come up with the same test suite, right? 179 00:08:15,440 --> 00:08:17,400 How cool is that? Because sometimes we feel that 180 00:08:17,400 --> 00:08:20,480 we only need a certain testers to come up with a comprehensive 181 00:08:20,480 --> 00:08:23,000 amount of number of tests. But I think the systematic way 182 00:08:23,000 --> 00:08:25,040 is actually to have any developers working on the same 183 00:08:25,040 --> 00:08:27,320 problem but they can come up with the same test suite. 184 00:08:27,400 --> 00:08:29,520 That I think is really really powerful concept. 185 00:08:29,920 --> 00:08:33,120 And I think it also becoming effective means that you write 186 00:08:33,120 --> 00:08:35,600 the right test, because I think it never ends right. 187 00:08:35,600 --> 00:08:38,440 You can come up with any number of tests as long as you can 188 00:08:38,440 --> 00:08:41,120 produce the test inputs right. And I think to come up with a 189 00:08:41,120 --> 00:08:43,320 certain right amount of test is very important. 190 00:08:43,480 --> 00:08:45,840 Which brings us to some of the techniques later on. 191 00:08:45,960 --> 00:08:49,000 One of the techniques that is commonly, I don't know, discuss 192 00:08:49,000 --> 00:08:52,240 in the software world is about. Test pyramid maybe? 193 00:08:52,240 --> 00:08:53,960 Let's start from there first. Do you think this is a 194 00:08:53,960 --> 00:08:57,080 systematic way to think about producing tests and what? 195 00:08:57,080 --> 00:08:58,920 Is your view about? This testing pyramid. 196 00:08:59,680 --> 00:09:03,320 I think the testing pyramid helps you to be pragmatic when 197 00:09:03,320 --> 00:09:05,720 writing those tests, because one thing is to come up with the 198 00:09:05,720 --> 00:09:07,800 test cases, right? So those are the inputs I want 199 00:09:07,800 --> 00:09:10,280 to give to my program and this is the expected output. 200 00:09:10,280 --> 00:09:13,520 The other one is writing this in code and making sure that this 201 00:09:13,640 --> 00:09:17,680 works nicely in your, let's say, development process, in your CI 202 00:09:17,680 --> 00:09:20,360 and etc. So for example, if you just 203 00:09:20,360 --> 00:09:22,840 write end to end tests, maybe your test suite will cost you 204 00:09:22,840 --> 00:09:25,560 too much to execute and then at some point this becomes a 205 00:09:25,560 --> 00:09:27,920 bottleneck, right? So I think the testing pyramids 206 00:09:28,040 --> 00:09:31,320 gives this pragmatic point of view on, hey, we're going to 207 00:09:31,320 --> 00:09:33,440 have to automate this test and we're going to have to maintain 208 00:09:33,440 --> 00:09:35,360 those tests and we're going to run them the whole day. 209 00:09:35,640 --> 00:09:38,120 And I like the idea of the testing pyramids very much. 210 00:09:38,240 --> 00:09:41,120 And the idea is that at the bottom you have unit tests, 211 00:09:41,120 --> 00:09:42,560 right? And why is it at the bottom? 212 00:09:42,560 --> 00:09:46,280 Because they are usually cheaper to write, they are cheaper to 213 00:09:46,280 --> 00:09:49,880 run, they tend to be more robust, they tend not to really 214 00:09:49,920 --> 00:09:52,160 fail, they are not flaky in general. 215 00:09:52,600 --> 00:09:55,280 And then you go up the pyramid, you have integration and end to 216 00:09:55,280 --> 00:09:57,360 end tests and you still have to do them right. 217 00:09:57,360 --> 00:09:59,760 You have to, but you do them a little bit less. 218 00:10:00,000 --> 00:10:02,520 Maybe you focus a little bit more in the unit test, maybe 219 00:10:02,520 --> 00:10:04,840 it's OK to maybe have some duplicated tests here if you're 220 00:10:04,840 --> 00:10:06,640 unsure. Are you covering the same thing 221 00:10:06,640 --> 00:10:08,360 or not. I think it's OK to make this 222 00:10:08,360 --> 00:10:10,800 sort of mistakes in the unit test, but it's integration and 223 00:10:10,800 --> 00:10:12,200 end to end test. You're going to prioritize a 224 00:10:12,200 --> 00:10:15,280 little bit more and I like this idea of the pyramids. 225 00:10:15,840 --> 00:10:18,400 Although you know in the software engineering at Google 226 00:10:18,400 --> 00:10:22,480 book I think from 2018, I think they bring a new perspective 227 00:10:22,480 --> 00:10:25,840 that I also appreciate very much that is forget about unit 228 00:10:25,840 --> 00:10:29,040 testing and integration testing, right, just separate your test 229 00:10:29,040 --> 00:10:31,680 suite between. Is this one fast enough that I 230 00:10:31,680 --> 00:10:34,680 can actually run it during a pre merge together with your merge 231 00:10:34,680 --> 00:10:37,960 request or pull request or is it super slow that I will have to 232 00:10:37,960 --> 00:10:40,040 run in a separate machine and etcetera. 233 00:10:40,400 --> 00:10:43,240 So separating the test suite in fast and slow makes a lot of 234 00:10:43,240 --> 00:10:45,240 sense to me. Because if you remember back in 235 00:10:45,240 --> 00:10:48,120 the 2000s, our big discussions were what is a unit test? 236 00:10:48,400 --> 00:10:50,880 If I'm testing two classes together, is this 2 unit tests 237 00:10:50,880 --> 00:10:51,640 or not? Right? 238 00:10:51,640 --> 00:10:54,840 And I think in 2023 we know that this doesn't matter at all. 239 00:10:54,920 --> 00:10:57,440 As long as it runs fast and it gives you proper feedback, 240 00:10:57,440 --> 00:11:00,080 that's good. So I like this new way of seeing 241 00:11:00,080 --> 00:11:03,160 things and it brings way less space for this type of 242 00:11:03,160 --> 00:11:06,000 discussions, right? Because I feel no one can argue 243 00:11:06,200 --> 00:11:08,320 that a slow test is better than a fast test. 244 00:11:08,600 --> 00:11:11,320 You can argue that maybe like integration tests more than unit 245 00:11:11,320 --> 00:11:15,240 tests, but no one can say a slow test is better than a fast test, 246 00:11:15,240 --> 00:11:16,520 right? So I like this new way of 247 00:11:16,520 --> 00:11:19,280 phrasing this. Yeah, let's go to the point you 248 00:11:19,280 --> 00:11:21,000 mentioned just now, right? Because they were asked some 249 00:11:21,000 --> 00:11:23,720 discussions and debates about people preferring more about 250 00:11:23,720 --> 00:11:26,280 integration tests rather than unit tests, some think that 251 00:11:26,280 --> 00:11:29,240 doing unit tests because you probably most of the things they 252 00:11:29,240 --> 00:11:32,000 feel is less valuable. So what is your view about this? 253 00:11:32,000 --> 00:11:35,320 I know it's it's probably a little bit more hot topics to 254 00:11:35,320 --> 00:11:36,960 discuss, but what is your view on this? 255 00:11:37,600 --> 00:11:40,080 I think I have a pretty clear opinion on this, right? 256 00:11:40,080 --> 00:11:43,400 And I think mocking can be dangerous for sure, because if 257 00:11:43,400 --> 00:11:46,040 you mock too much, then at the end you're not testing anything. 258 00:11:46,040 --> 00:11:48,720 So you want to test as much as possible real behavior or 259 00:11:48,720 --> 00:11:50,640 behavior that will look like in production. 260 00:11:50,920 --> 00:11:54,200 But at the same time, you don't want to be slowed down by things 261 00:11:54,200 --> 00:11:57,080 that you don't control so much. For example, let's say you're 262 00:11:57,080 --> 00:11:59,840 writing a piece of code that makes a call to web service that 263 00:11:59,920 --> 00:12:02,720 is developed by another team, and suddenly for you to really 264 00:12:03,000 --> 00:12:06,320 run this test, you need that web service available to you, right? 265 00:12:06,320 --> 00:12:08,920 And this becomes very quickly a pain. 266 00:12:09,320 --> 00:12:12,920 So in this case it's mocking makes a lot of sense and the web 267 00:12:12,920 --> 00:12:14,120 service you don't control so much. 268 00:12:14,120 --> 00:12:15,880 Let's give an example of something you control a 269 00:12:15,880 --> 00:12:17,600 database. Should I mock my database or 270 00:12:17,600 --> 00:12:19,440 not? To be honest, I believe my 271 00:12:19,440 --> 00:12:21,800 opinion is that you should not mock your database, because 272 00:12:21,800 --> 00:12:25,160 today you can make tests with database so fast that you can 273 00:12:25,160 --> 00:12:27,880 actually run them during your pre merge time and you get 274 00:12:27,880 --> 00:12:30,040 feedback very fast. So why would you mock something 275 00:12:30,040 --> 00:12:32,720 that is not really preventing you from writing the test in an 276 00:12:32,720 --> 00:12:35,840 easy way and to run it fast. So I think that's the trade off 277 00:12:35,960 --> 00:12:38,560 that needs to happen. I think it's not about writing 278 00:12:38,560 --> 00:12:41,280 integration tests or unit tests, but it's about writing lots of 279 00:12:41,280 --> 00:12:43,720 tests that are fast in the end and that you can have full 280 00:12:43,720 --> 00:12:45,920 control over. And those are the things you 281 00:12:45,920 --> 00:12:47,560 should mock, right? Things that you don't have 282 00:12:47,560 --> 00:12:50,240 control over. And then of course, if you go 283 00:12:50,240 --> 00:12:52,080 back to the testing pyramid, let's say you're mocking this 284 00:12:52,080 --> 00:12:54,280 web service. So you can write lots of unit 285 00:12:54,280 --> 00:12:56,680 tests, you know, super fast tests that just mock this web 286 00:12:56,680 --> 00:12:59,360 service, but you can still have one or two or three integration 287 00:12:59,360 --> 00:13:01,840 tests that are a bit more expensive that make real calls 288 00:13:01,840 --> 00:13:04,600 to this web service. So you see that things work when 289 00:13:04,600 --> 00:13:06,120 you put all the components together. 290 00:13:06,560 --> 00:13:08,680 But you know something that I always say is you should not 291 00:13:08,680 --> 00:13:11,960 write an integration test that could have been a unit test, 292 00:13:12,200 --> 00:13:13,520 right? You don't need an integration 293 00:13:13,520 --> 00:13:15,800 test to exercise an if statement in your code. 294 00:13:15,840 --> 00:13:18,880 Just write a unit test for it. Leave integration test for what 295 00:13:18,880 --> 00:13:21,720 it really pays off, that is to find integration bugs. 296 00:13:24,520 --> 00:13:27,080 I really love your pragmatic approach to answering this 297 00:13:27,080 --> 00:13:29,320 question so I fully. Agree as well in terms of 298 00:13:29,320 --> 00:13:31,760 control, right. So first think about do you 299 00:13:31,760 --> 00:13:33,960 control that and especially if not just the. 300 00:13:33,960 --> 00:13:35,720 External service or infrastructure. 301 00:13:35,720 --> 00:13:38,480 Related time is also probably one thing that you want to 302 00:13:38,480 --> 00:13:40,120 consider. Right time is something you 303 00:13:40,120 --> 00:13:43,240 cannot control by itself, but you can actually create like a 304 00:13:43,240 --> 00:13:45,400 fake system or mock it sometimes. 305 00:13:45,640 --> 00:13:47,920 So I really love the way you explain about this. 306 00:13:48,320 --> 00:13:50,800 So let's move on to maybe some of the other techniques right 307 00:13:50,800 --> 00:13:53,360 where you have talked about unit tests, integration tests, end to 308 00:13:53,360 --> 00:13:55,240 end tests. In your book you actually 309 00:13:55,240 --> 00:13:57,440 mentioned couple of testing techniques. 310 00:13:57,680 --> 00:13:59,640 So let's start with the first one which is called the 311 00:13:59,640 --> 00:14:02,920 specification based testing. And it's actually very 312 00:14:02,920 --> 00:14:05,280 interesting the way you start by expanding this. 313 00:14:05,320 --> 00:14:08,040 I would assume like some people would start with unit test, but 314 00:14:08,040 --> 00:14:09,880 you start with specification based testing. 315 00:14:09,960 --> 00:14:12,920 So maybe tell us more what is specification based testing, Why 316 00:14:12,920 --> 00:14:14,400 you prioritize that as the first? 317 00:14:15,240 --> 00:14:17,280 Cool, Yeah, So what is testing right? 318 00:14:17,280 --> 00:14:19,400 So testing is about trying to find bugs. 319 00:14:19,840 --> 00:14:22,040 And how do you do this? Because you compare what you 320 00:14:22,040 --> 00:14:24,640 expect the program to do with what the program does, right? 321 00:14:24,840 --> 00:14:26,840 And for you to do this you need to know what the program should 322 00:14:26,840 --> 00:14:29,000 do. Where is this information in the 323 00:14:29,000 --> 00:14:31,840 requirements? And I'm not saying like a Word 324 00:14:31,840 --> 00:14:34,480 document that contains the requirements or UML, it doesn't 325 00:14:34,480 --> 00:14:35,960 matter. The requirements can be in your 326 00:14:35,960 --> 00:14:38,400 mind at some point. There's this notion of what the 327 00:14:38,400 --> 00:14:41,920 program should do and specification based techniques 328 00:14:41,920 --> 00:14:45,760 are the ones that help you look at the requirements and identify 329 00:14:45,760 --> 00:14:48,320 interesting test cases. This is not new. 330 00:14:48,320 --> 00:14:51,560 Again, this dates from the 80s and we became very good at 331 00:14:51,560 --> 00:14:54,200 coming up with techniques. And basically what I showed in 332 00:14:54,200 --> 00:14:56,000 my book is to look at the requirements. 333 00:14:56,000 --> 00:14:59,120 It's quite easy to see those are the inputs of the program. 334 00:14:59,280 --> 00:15:01,560 This is sort of what the program needs to do in the output. 335 00:15:01,720 --> 00:15:05,240 Those are the different paths that the program may take, so on 336 00:15:05,240 --> 00:15:07,080 and so forth. And you can look to all of this 337 00:15:07,240 --> 00:15:09,520 and then get inspiration to write your tests. 338 00:15:10,080 --> 00:15:14,120 And the one technique I show in my book is actually a very basic 339 00:15:14,120 --> 00:15:16,880 one that basically says look at the inputs of your program, or 340 00:15:16,880 --> 00:15:19,040 the method you're testing, or the component, whatever. 341 00:15:19,320 --> 00:15:21,880 What are the inputs? Separate them one by one. 342 00:15:21,880 --> 00:15:25,120 Let's say your function receives 3 inputs, an integer, a string 343 00:15:25,120 --> 00:15:27,000 that represents whatever, and the list. 344 00:15:27,200 --> 00:15:29,920 Look at them separately and explore their domain. 345 00:15:30,080 --> 00:15:32,680 So let's say this is string. What are the possible strings 346 00:15:32,680 --> 00:15:34,880 that can come here? Are there any special strings 347 00:15:34,880 --> 00:15:36,840 that would make the program to do something different? 348 00:15:37,120 --> 00:15:39,960 You do this per input. And why you do this separately? 349 00:15:39,960 --> 00:15:42,640 Because it's just much easier for our brains to process small 350 00:15:42,640 --> 00:15:44,800 things, right? So you do each one of them 351 00:15:44,800 --> 00:15:47,400 separately, Then you try to look at all of them together. 352 00:15:47,720 --> 00:15:50,960 You look for other possible corner cases and so that might 353 00:15:50,960 --> 00:15:54,000 be explicit on the documentation or the requirements. 354 00:15:54,400 --> 00:15:56,640 And then and only then you come up with test cases. 355 00:15:57,160 --> 00:16:00,160 And that is sort of the idea of specification based testing, 356 00:16:00,160 --> 00:16:02,800 that you start your tests from what the program should do and 357 00:16:02,800 --> 00:16:05,800 not from the implementation. And I actually like this very 358 00:16:05,800 --> 00:16:08,040 much because as a developer, right, the person writing the 359 00:16:08,040 --> 00:16:11,120 codes that I'm about to test, that gives me the opportunity to 360 00:16:11,120 --> 00:16:13,480 disconnect from my implementation and really focus, 361 00:16:13,480 --> 00:16:15,600 hey, this is the input that I'm going to pass through the 362 00:16:15,600 --> 00:16:17,200 program. This is the expected output. 363 00:16:18,000 --> 00:16:19,840 So this is my suggestion. If you really want to be a 364 00:16:19,840 --> 00:16:22,440 little bit more systematic when it comes to testing is first 365 00:16:22,440 --> 00:16:25,720 step is start writing tests or creating test cases from the 366 00:16:25,720 --> 00:16:28,800 specs from the requirements. So when we talk about 367 00:16:28,800 --> 00:16:31,760 specification based testing, I think people always, I mean not 368 00:16:31,760 --> 00:16:35,440 always often associate with BDD right Behaviour driven design 369 00:16:35,640 --> 00:16:38,640 and sometimes it's like Gherkin type of language and things like 370 00:16:38,640 --> 00:16:40,440 that. What's your view of this? 371 00:16:40,640 --> 00:16:44,120 Do you always have to come up with BDD type of specification 372 00:16:44,120 --> 00:16:46,640 test or is there some other types of tests? 373 00:16:46,640 --> 00:16:50,000 That we can also use. Yeah, very good question and 374 00:16:50,000 --> 00:16:52,480 maybe that's the difference between my book and other books. 375 00:16:52,480 --> 00:16:54,920 Usually when people talk about specification based testing, 376 00:16:54,920 --> 00:16:57,720 they are focusing on a very coarse grained feature from the 377 00:16:57,720 --> 00:17:00,160 point of view of user what should I test? 378 00:17:00,600 --> 00:17:03,600 In my book I show that you can do this at method level for 379 00:17:03,600 --> 00:17:05,960 example, or at class level, because as a developer that's 380 00:17:05,960 --> 00:17:08,359 sort of the units you're always handling with, right? 381 00:17:08,760 --> 00:17:12,440 And I think to me BDD makes more sense when you're looking at the 382 00:17:12,440 --> 00:17:16,400 big picture and looking at the whole functionality from really 383 00:17:16,400 --> 00:17:20,200 the point of view of the final user and the specification based 384 00:17:20,200 --> 00:17:21,400 techniques you can apply in both. 385 00:17:21,800 --> 00:17:24,760 Now should you write tests in a BDD style? 386 00:17:25,160 --> 00:17:26,920 I think that's really a matter of taste. 387 00:17:27,160 --> 00:17:31,320 I am personally not a BDD fan, so I don't like tests using BDD 388 00:17:31,320 --> 00:17:33,480 style. I don't use Cucumber, that's 389 00:17:33,560 --> 00:17:36,320 just not my thing. But I see where this comes from, 390 00:17:36,320 --> 00:17:38,160 right? And I don't think you know in 391 00:17:38,160 --> 00:17:40,960 practice this is too different. It's really telling you to focus 392 00:17:40,960 --> 00:17:43,040 on the specs, on the behavior of the program, right? 393 00:17:43,040 --> 00:17:44,600 And coming up with the test cases. 394 00:17:44,840 --> 00:17:47,160 Tooling is a matter of personal taste in the end, right? 395 00:17:47,400 --> 00:17:49,560 As long as you're looking at the behavior of the program, what 396 00:17:49,560 --> 00:17:53,000 you expect from it, I think this is a great step towards a good 397 00:17:53,000 --> 00:17:57,120 testing. I hope you enjoyed this short 398 00:17:57,120 --> 00:17:59,360 clip from Techly Juno favorite playlist. 399 00:17:59,680 --> 00:18:02,720 If you find this episode useful, please help share it with your 400 00:18:02,720 --> 00:18:05,680 friends and colleagues who you think would also benefit from 401 00:18:05,680 --> 00:18:08,960 listening to this episode. And if you want to listen more 402 00:18:08,960 --> 00:18:11,960 from this conversation, please go back and listen to the 403 00:18:11,960 --> 00:18:14,320 original full conversation with my guests. 404 00:18:14,800 --> 00:18:18,120 Stay tuned for the next Techly Journal episode, and until then, 405 00:18:18,280 --> 00:18:18,880 goodbye.