You can listen to the podcast and read the show notes here.
Welcome back to the show. And today we're looking at the fundamentals of unit testing, be DD, which is behavior driven development and mocking and using test box and Dropbox, do that, and I'm here with Alma Gattaca. And if you don't know her, she is a cold fusion developer been doing it CFL on cold fusion for six years now. And she is giving a talk on this topic at into the box. So we will cover what is unit testing and why everyone listening should be doing it. And guidelines for writing great unit tests. And then also we'll look in detail at test box. And what it lets you do and how to structure unit tests using it will look at what marketing is and how to do that using mock box and why you want to do that. And we'll also look at behavior driven development or BDD and why you should be doing that and how to do it using test box and mock box together. So welcome oma.
Uma Ghotikar 1:00
Thank you. Thank you for having me. I'm glad to be here. Yeah.
So what is unit testing? For those few people listening? who may not know? Yeah,
Uma Ghotikar 1:10
so yeah, so you're testing is a level of software testing, where, you know, individual units are components of a software testing. And what that means is, the unit is the smallest piece of functionality that can be tested in isolation. So having said that, they are definitely low level they are, they are of small scope. And in procedural language, it could be a function, it could be a method and an object oriented language, it could be a class, our method belongs to a class. So basically, it's the smallest piece of functionality, that's what unit is. And the entire purpose of unit testing is to validate that the each unit of software is performing as design. So that's why we should do unit
testing. That's a brief answer to now why, why is it better to do you write all these unit tests for all the functions and methods you have? and so on, instead of just letting your testers go crazy and try out the app? Why is it better to do it through unit tests?
Uma Ghotikar 2:17
Okay, so yeah, let's see if we don't have unit tests in place. And if the developers are developing code, and first of all, we would need us to be dabbling. In order to test out let's say, developers develop UI and all code. And our code is written front and back, and everything is written. And there is no unit testing, please. And we haven't done any integration tests. And we are just now finding a browser. And let's say we have a form. So now developer, or whoever testing that code, that piece of functionality needs to open that form and submit that form. Or, first of all, they need to fill up all the fields, make sure that validation is working. And if there are any Hidden Figures, so
it depends, like, you have to remember all the use cases, if to just focus on one for like, focus on like, one entire piece of functionality is working or not. But and again, let's say in future, if that could get changed for some reason, then you have to redo this entire thing, you don't know which which field has changed, and you will redo the same thing. And you have to remember, first of all, all the n number of use cases that were
that are that are tested. But what happens with unit test is, so each unit
supposed to have a test case coverage around it. So that, let's say a developer has written a test, and they have now build the code around it. So the basic idea is to write the test first. And then to write the code to make that test pass. That's the basic idea of unit testing is, so this has been basically reactive programming. So we know what always my code is going to fail. So now knowing that I'm going to double up my code, and let's see. So unit test, first of all, give us instant or immediate feedback. So if I developed something, and I run unit test, boom, I know this is failing. So I, I can immediately fix that good. I don't have to wait for, you know, my entire piece of functionality to be built, and then running up the test in the UI or so that's the basic idea why, okay, you know, unit test way rather than the traditional way. Yeah, so
it makes ensures that you're testing all of the methods and functions, all the pieces of the code use cases. And then also, you know, unlike having someone in QA test it when, if you've written unit tests, they can be automated and repeated every time you edit the code. Exactly. Oh,
Right. So if we want to write unit tests, what kind of suggestions you have for guidelines for writing them?
Uma Ghotikar 5:06
Sure. So first of all, the unit test must be fast, what that means is, so
they should be able to provide us the immediate feedback. And that's the key point here. Because while refactoring code are while building while developing code, you need immediate feedback, like in seconds, for milliseconds, I'm talking in terms of unit test right now. Because if they are taking more time than the entire process, like then the developers would
rarely running. And then that basically loses the entire purpose of having it. So they should be fast. And to make that fast. So what makes unit tests to run slow, so that you are if you're talking out to databases, if you're talking to file systems, our API, so external calls like this, so you have to mark those calls, and then make sure your each unit is kind of isolated, so that
so that your test would run fast. And you're focusing on just one piece of small piece of functionality there. So make sure your units are isolated.
The second thing is,
Uma Ghotikar 6:21
the code becomes modular, if I'm writing a unit test, I'll make sure that I'm breaking down the code to the smallest level possible. So that becomes so that way, my code is more modular. And that That way, I can reuse that piece of code over and over again. So that's one more thing. So make sure that your code is modular. So that's one guideline, the next thing is make sure that your tests are independent, what that means is, so there is no specific
guarantee that, you know, if we are having multiple tests, test cases, so there is no particular guarantee like, you know, which test will run for, so make sure they are independent of each other. So, not one test should be dependent on runtime of any other. So that's one thing, then they should be robust. What that means is,
no matter what environment you run the test on, or no matter what time of the day test on or no matter what day tests on, they should always produce the deterministic results, like the same results are the times that a robust, make sure you are maintaining your test as you change this. So if you change your code, make sure that your tests are in sync with your code. And they should be meant they should be maintained as we go along. And the last thing is,
they should, they should have a clear defined defined purpose. So make sure that your each of the unit test is serving a clear purpose. like okay, I'm focusing on this piece of functionality. So I know what my preconditions are, that's my State of the that's my state of the world before running that test will welcome welcome to this part, when we talk about given when then. But that's possible, but basically the given stage, you know, what, what the preconditions are, and now, you know, what is your what, what do what is the action that causes that test run. So that's basically when part and then what, what is the testable outcome that you're expecting, that test is giving. So that's basically the den part. So basically, that test is serving a clear defined purpose. So make sure each of the tests has cleared. So let's say, I don't know it. So I know like, okay, it should do this, and this and this. So I know once I run the test, I'm sure that these three things are running for sure. So that's, that's the main thing you should you should have a clear defined purpose. And yeah,
so if you if you're a confusion app is a model view controller style app, which many modern apps are, you're mainly testing the model part of this where there's actual, you know, things happening, rather, you're not really you can't really test the view, right? That's all HTML. And they're not really testing the controller, I imagine there may not jesting actions happening inside the model,
Uma Ghotikar 9:15
right. I mean, most of my testing was done around the model, like the service layer components I have done, you know, let's say very little bit of controller testing. But majority of it is no focusing on service layer. CFC or components. So model Yeah,
Okay, great. So, and just to be clear, you know, unit tests are only one part of testing, you know, you you may be doing integration testing, or you might be testing the, the UI or all kinds of other things. But this is just to make sure that the, all the functions and objects, you've written a working correctly as you code or refactor, right,
okay, so let's talk a bit about x unit, because that's one of the things you can use for this and how you use that if you're doing behavior driven development.
Uma Ghotikar 10:16
Sure. So MX unit was the only available framework until test box came into picture. So all those unit tests were written using x unit style. And that's basically the test driven development. So what that does is, so
Uma Ghotikar 10:35
when functionality is getting developed, any developer would write the test for us, and make sure that test is failing. And once the test fails, you just write enough code to make that test pass. So that's how you go. It's like a reactive programming. So as I already spoke, so that was excellent styles of testing. I have done only literally bit of that. But I have most of the time I have used BDD style of testing that's,
like, available from test box. And it is a major evolution to test driven development in my opinion, because it is I mean, it still has its roots in that TDD, but it has taken TDD to a whole new level. And
so yeah, I have I'm mostly big fan of BDD now, because that that produces clear and readable outputs, creates documentation. And I know where to start, or, you know, what, what is to be tested and what not to test. So it becomes clear when using BDD.
Now, you mentioned test driven development, TDD, and then behavior driven development. BDD. But what exactly sound the same thing? Well, what's the difference?
Uma Ghotikar 11:57
Okay, sure. So TDD as a, the name suggests, it's festive and development. And what that does is it focuses on methods, first of all, they're very developer oriented, the focus is on each smallest method, or functions in the component level. In Cold Fusion, we call it CFC. So it focuses on CFC level. So you, even though if you have all of your test your test coverage ready for all of your functions. And if you just if you just run all the tests, and you create a report out of that you don't know if your software is
specified, satisfying your customer requirements. So that's one drawback of that. And
the main problem with that is, sometimes even developers give up it, I mean, it is really tedious to write those test because they are very much focusing on just one unit one, not one, just smallest function, and not bothering about the entire software specifications. So
and also in while doing that, you have to use marking a lot of times, because you are isolating basically the behavior of the one function at a time. So sometimes you are just testing, let's say, I have a function a. And what that does is it depends on function before. So it gives calls to function B, and functions See, and there is a fence around that. So if I'm walking function V and function sees, so basically, I'm just testing if it's there. So it it is like, really okay, that it becomes really dumb to test that function, Aiden so sometimes it is
very geeky, let's let's put it that way. So yeah, so But I mean, it has its advantages, but it has its drawback.
Okay, so in test driven development, Europe Greetings, low level unit tests. And in behavior driven development, you're looking at a high level use cases that the user would go through in, in the gap. So, uh,
yeah, so let's say
Uma Ghotikar 14:12
while doing TDD, first of all, sometimes we don't know where to start. Because we are focusing on a inside level. So so we don't know where to start. Or we are not sure exactly what to test or what not to test in one of the entire
in the entire suite. So but what happens with behavior driven development is, so we would start with the user story or acceptance criteria, so we know what our system is supposed to do. And then we would break down those user stories into smaller scenarios. So we have a clear defined scenarios. And then for each scenario, we would
code those two nose into specifications, which will give us a clear idea or Head Start to, you know, okay, this is our, this is our software's acceptance criteria. Now, we are breaking down to this specific scenario. And now we are supposed to code to make that scenario work. So we have a clear idea where to test I'm in where to start. So that's one big advantage.
And now, you mentioned us a story there. Yeah. What, what's an example of a story? Because not everyone has come across use cases and stories, they may be thinking, What on earth are we talking about here? So a concrete Can you give a concrete example of what you mean by a story in a scenario?
Sure. So let's say
Uma Ghotikar 15:42
this is this is this is just a hypothetical one. So let's say user is supposed to share their feedback through one of the farm on the website. So that's a big level story. And
while breaking down that into scenario, what I would do is, okay, so as an application user, I want to, I want to, I want to be able to submit this form. And once I submit this form, I should be able to get a confirmation message on my screen saying that, Oh, hello, your feedback was submitted successfully. So that's basically a hypothetical example of one story. And when you convert that into scenario, so there is one scenario, so Okay, I'm a user, I will fill out a form. And when I hit submit, I should see the message. So that's breaking down story scenario, what happens at each level? And when you have these kinds of scenarios, you know, what your system is supposed to do? Is that helpful? Yeah,
that that helps explain it. So,
Uma Ghotikar 16:52
okay, so well, so basically, this is outside in, we would start at the very high level specification, and then, then we would just break down break down and go inside, hmm. And you you do this using test box, right. So again, we we are not doing end to end testing. Because sometimes I hear that kind of confusion, like, you know, BDD is, you know, end to end. So that's, that's right. But here, what we are trying to do is, we are trying to bring in the BDD syntax into the unit testing using test box. So our testing is still going to be, you know, test first and cold later. So, our, it's still going to be
on the unit test level. And it's still going to be test first and cold later. But we are bringing in the BDD syntax. So what does box does it for us is, it is a framework that will do that, first of all, that supports both excellent and styles of testing. And we really styles of testing. So and it is
open source. So that's great thing.
Uma Ghotikar 18:00
And yeah, it is a tool that lets us do that. So it is bringing us the beauty, the syntax for us, it won't do be ready for us. But we have to using that tool and framework and using the features and
we really style Well, that's that's available. We are just we are just supposed to write either x unit or video styles of testing.
Okay, so textbooks is free to get to us because it's open source, and it uses a standard syntax
for this, is that right? Or is its own custom syntax? Or
I'm not sure if I follow that. But then
when when you're writing tests in textbooks, what you know what, what language are you using?
It is the FMS, so I mean it does that. Oh, okay.
So you're writing the test sincere from hell?
Yeah. Okay. I mean, I don't
know, I haven't used it. I know everyone listening. It's used it. So that's why Boston Yeah, I
mean, it supports any CFL
Uma Ghotikar 19:14
projects, not just the box projects, but it's about the other standalone.
Okay. And so you write you write your tests in cold fusion language inside test box,
Uma Ghotikar 19:29
I'm writing test to test my cold fusion product,
right. But the language you use to write the tests, that's just regular confusion, it's not some wacky XML language, or no, no, no. Okay. Yeah. So test box keeps all those tests organized, and helps you run them, or what exactly is test box doing for you.
Uma Ghotikar 19:54
Um, so this box is, this book does a lot of things. First of all, as I mentioned earlier, their ability and excellent and styles of testing. And then to support that it also ships with more box so we can have it What that means is, it has stabbing and marketing companion available. So that's another big advantage of using text box. And it has lifecycle methods which are available to us,
such as I won't go into too much technical leaders. But what they do is they allow us to set our
like before before running the test, they allow us to do the setting of the test. And then after the test is run, they allow us to tear down things. So we have lifecycle methods available. Then we also have automation capabilities in there, we have tons of managers available they're using which we can do our certain statements or expect statement, we have reporters
that done something
right. So what what do you Why do you like using test box to do your behavior driven development,
Uma Ghotikar 21:15
so does it so first of all, the biggest advantages, it supports really style of testing, which is very easy to understand our It is easy to pick up. The next thing is it supports Mark box, so you have marketing companion available to you. So it is it is open source, and you have lot of
online support available for that there is an entire
test on if you go to test box website, you have the entire documentation available there for free. So it if you're stuck at any point, you just refer to that. And it is it is easy to solve your problem. And we have a great community available on SEO from the Slack channel. We have testing channel there aren't we have lots of channels there. So if you ask questions about Xbox, you, you can get answers right away.
That's great. So when you're writing unit tests, what's the general structure you use in test box for that,
Uma Ghotikar 22:24
so general structure is OK, now we are coming back to again, given when then kind of thing. So it is a full face test. The first phase is the setup, which is also called has given in this, you would set your things such as you know, okay, I would set up my component under test or it is also called a system. And it is so I can do
basically, okay, this should have this, this is the my predefined condition before the test runs. So that's the first place. second phase is the exercise phase, or it is also referred to as like whatever comes in that when block
it is at this time, we are exercising our system under test the sector it is the verify stage here, we are actually testing that if our test is producing the same results as we are expecting. So this is the den phase of given when then. And the last step is the teardown also call this cleanup face. And in if you're using test box, you have lifecycle methods, such as after all, or after each to do that tear down for you. So that's the general structure for writing unit tests. But sometimes some of the unit tests don't need to down because they don't talk to external systems or databases. So they don't have really done anything that needs to be cleaned out. So sometimes only first three phases. Oh, salty. Like, that's the structure for some of the test.
Okay, great. And what what kind of things would you be cleaning up in the tear down phase,
Uma Ghotikar 24:08
I'm sure. So let's say if I
if I added a record in my point of the table, so I want to make sure and I perform my test on that. So I'm going to make sure that that record gets cleaned up. And I don't leave that in my database. So that kind of thing.
Oh, ok. So unlike previously, when people did manual testing, and you had bunches of test data to clean up, you don't have to do that, because you automatically clean it out,
Uma Ghotikar 24:40
right. So whatever you set up in the setup phase, you have to clear that
I'm very tidy.
So you mentioned Mark box there. And I'm assuming that's what you used to do marketing. So tell us what marketing is and why you like Mark box feed it sure. So
Uma Ghotikar 25:04
a testable that or, or it is also a fake implementation of something
of a real objects. So basically, what Mark does it It simulates the behavior of the real object, and why we have to do why we need the mocking, because let's say sometimes not all functions can be ridden or can be Can Can, can, can live in isolation. They they have external dependencies such as they either talk databases or file systems or external API's are, they just, they are just calling out another function. So you have a lot of dependency when you're writing a code. And sometimes it is
impractical to incorporate these kind of dependencies into your unit test. So
example would be if you are doing let's say, if you are writing a system that involves credit cards, validation credit cards, though, so while running your unit is you don't want to reach out to actual, you know, credit card validation and actual system that is charging your card. So that time you would use marking and make sure that you are simulating that kind of behavior. So that's, that's the basic idea of marking, it just simulates the behavior of a real
object. And I'm using Mongo box for that, because Mark box has a lot of mocking capabilities available to us.
First of all, it is it it it ships along with test box. And it has advanced level of marketing and stuffing capabilities.
What that means is, it has got a lot of methods, marketing methods that are available to us. And it has also a lot of verification methods by which I can make sure that, okay, this, this was my mocked object, and I just want to now make sure that that perform, or that that was behaving as I was expecting it to be. So it has got a lot of verification methods available. And yeah, it it's great. My box is great.
Now sounds good, just help us understand why you'd want to mock out something, what's the benefit of doing that?
Uma Ghotikar 27:36
Okay, so let's see, I have a file system and one of my function,
okay, I'm copying file from function, but from point A to point B. And I want to make sure that while copying that I didn't lose any of my data, like file copying was successful, I want to make sure that work. So if we are talking real file system in the testing, I will have to make sure that file exists at part A. And then after the test is run, it went to part B, and then read that content and make sure everything was fine. But again, it's gonna if since we are reaching to the actual system out here, it's going to increase the time. And unit tests are supposed to end in milliseconds. So that are seconds. So that won't be possible. And if you have network interruptions or anything like that, even if the even if your core of file copying is working, because of network interruptions, you you don't know what happened. Like, if your code fail a while moving the file or, like, really, there was any kind of network interruption so so just to focus on that file copying code, I just mock out the entire file system there. And I won't have to use the fake fake fake file system path. And that way I can, I can make sure that Okay, my file copy code works correctly.
Okay. So one of the benefits here is that if you haven't completed the whole program, you can still test straight because, yeah, missing pieces of filled in walking bar,
Uma Ghotikar 29:13
it don't need all the collaborators, it marks are just replacement for those collaborate and to that where we can like, really isolate the behavior of just one smallest unit that we are doing. And this
mock box work together with test box or
Uma Ghotikar 29:31
Yes, they work together. Yeah, right. Like hand in hand.
Okay. And is mock box also open source or? Yeah,
it chips chips along with this box.
Okay, so you just install stool test box, and you get more books along? Yeah, right. So you mentioned behavior driven development?
Why do you like behavior driven by elements so much? What does it do for you as a developer, I'm
Uma Ghotikar 30:03
sure. So behavior driven development, once I have all my tests written, it gives me a nice output, like readable output, okay, so it actually brings the given when and then statement. So I know what is happening at each desk level. So it produces nice documentation at the end. And that we know our requirements are really getting satisfied. The next thing is with behavior driven development,
I'm focusing more on I'm focusing more on
what my system is.
Uma Ghotikar 30:45
Okay, let me let me reframe this statement. So with behavior driven development, I'm focusing on what a system should do and not on how it should be implemented. So I'm not focusing on each don't like each CFC or, you know, just one method at a time. So,
so that's, that's, that's easy to
I mean, that, that, that that is
Uma Ghotikar 31:15
that is a natural flow, I feel that way. So
have you found that it means you have fewer bugs in your code, or easier bugs to fix, or?
Uma Ghotikar 31:27
Yeah, I have, I have had some cases where I have found bugs. And
fortunately, I had unit tests in place. And it was easy to fix those without having to wait to know, you know, QA person finds it.
And then how does this fit in your development workflow? Are you using some continuous integration tool, like Jenkins? Or, oh,
Uma Ghotikar 31:56
we are using Jenkins. But ok, so I'm, I'm not covering continuous integration part in my this CD. So I'm not sure how much we want to talk on this. But yeah, we are using Jenkins and continuous integration. So you,
you've got all this automated every time you make the bill reruns all your tests, right, exactly. Great. So anything else about test box or lock box and behavior Driven Development you want to share?
Uma Ghotikar 32:26
If you have not tried out, just go to their website and try it out today? It's pretty cool.
Great. So let's shift gears now and look at some other questions. more general about cold fusion? Why? Why are you proud to use cold fusion?
Uma Ghotikar 32:43
Oh, that is great question. So let's see. I started cold fusion back in 2011. And ever since I'm using cold fusion so that time I was really like a new to cold fusion and I'm did not know anything about it. But I think from my personal experience, it was very easy to pick up and easy to learn. And there is a lot of online resources available and what else it is it is a great for rapid development.
As I already mentioned, we have great super metal community on out on slack. It's already I think, more than 2000 members out there. So it's really great. And
I like cold fusion. Like, I am using it for six years. And I really like it prior to that, prior to that I had worked on Java, but compared to that I've been cold fusion is much easier to learn and know doing. Development wise. It's, it's, it's, it's great. And with and with all these box products that are coming now. Or
it is it is it feels like it's Edwin's. More advanced language now.
Yeah. I think it's a more modern advanced language than Java is at this point, right? Yes, in the CFL. But also in the environment that you get with all the box products and other products are out there.
Uma Ghotikar 34:17
Right. It is really turning out to a modern these days. I agree. Yeah,
yeah. So what would it take to make cold fusion more alive this year,
Uma Ghotikar 34:33
we already have a lot of conferences going on. So just try to attend those. Make sure you meet people network with those people and try to gain and spread knowledge cold fusion knowledge as as as much as possible and be active in the CML community. And just just try to grow the community every day.
Great. So you're going to be speaking it into the box. What are you looking forward to that conference?
Uma Ghotikar 35:07
I'm really excited about it. First of all, this is my first ever conference. I have not attended anyone before. So I'm really excited about this. And I'm looking forward to I guess they're over 28 sessions around. And also there is a pre workshop
pre conference workshop. So I'm going to attend command box deep dive. So I'm really excited about that. And again, that lots of sessions and as I mentioned, this is my first tech first conference. So basically, I'm just excited about the entire new experience.
Yeah, it was a great conference when I was there last year. Lots of cool new technology. interesting people. Very friendly. Exactly. So meeting new people. Yeah,
and you're going to be there this year as well.
I won't be there this year. But I'm sure I'll go in another year. I have a conflicting event. So okay. And then the other nice thing is, it's in Houston, Texas. So for those of us in the northeast of United States, it's a little warmer,
but in April, it's not like crazy heart. So it's Yeah, it's just very pleasant. And of course, you get the Texas hospitality as well. So yeah, great abandon until that's it.
lots to see in Houston. So yeah, museums and culture. So and of course, Texas barbecue and can't get away from that.
So So if people want to find you online, one of the best ways to do that, so
I'm on LinkedIn,
Uma Ghotikar 36:53
that's the best way to reach out to me.
Okay, and we'll put that link into the show notes along with all the things you mentioned, and good luck with your talk this year, and thanks so much for coming on the show. Thank you
Uma Ghotikar 37:06
so much. It was great talking to you. I'm really looking forward to the conference.