I am Sumana Saha. I'm here to present um a topic which is a very um yeah, very uh attractive at, at this moment, a software development uh uh uh department which is a test driven development.And I'm here to talk about something about the TDD and how we can do it and everything. My name is uh Sumana Saha and I am a software engineer. I work, I work at rate pay M Biha. It is located in Berlin, but basically I am from India and uh I have done my bachelor's currently, I'm doing my master's in software engineering. I'm, I'm really passionate about clean code and writing microservices and various type of programming and stuff like that. So if you're really interested to talk to me, you can just ping me in, in any kind of social media like linkedin. I have Twitter, I have so uh after the session, I can share my, my contact details as well, so you can Yeah. Yeah, happily uh share a connection request to me. Uh a fun fact about me that I'm a very much a cat lover person and not so fun fact. It's like I'm a perfectionist that is like sometimes difficult to, difficult to um mitigate my own expectations. So it's, it's really, it's really the, the, yeah, the quality I have right now. Ok. And now what is the agenda for today? First of all, I would like to ask you that.

Do you anybody have experience with TDD or do you know what is actually a TDD a lot? If you can just drop a message, it will be really beneficial for me to understand. Like, do you have any idea what is it and how to do it and stuff like that? Thank you, Irina for writing. Yes. So I think you have the understanding. Yeah. Uh yeah, curry as well. So uh today I can share uh I can share the rules and uh I would like to show a simple, simple, very simple way to write the test cases using KTD and how we can actually do it. And so mm don't, I mean, without wasting any time this agenda is like, I'll talk about a history, I'll talk about what are the connection with A G? I'll talk about a practical approach. Then the pros and cons what people say about Edd and then some useful resources you can look up, look up to later on. OK. First of all, what is TDDTDD means that uh the abbreviation stands for trace driven development and how it works. First we write test, that means what exactly we write test there is a requirement. Let's say you are asked to do uh for example, uh phone number validation. So what exactly you do? So you, you first start with writing tests.

So in a traditional way, as a developer, I have seen the other side of the picture that we tend to write the productive code. But no, here in this approach, we will write the test first. So what wi what will happen? So when we write test, it will show us a lot of errors, the test will fail because there is no productive codes are written, then we will go to write the productive code. So now when the productive code is written, the very, it's a very simple simplest like just to pass the test case, then we run the test case, then it passes. Now we go to the test class again to reflect on the test. And then we see the test is keep passing, that means whatever productive code we have written is good to go. Then again, we write more test, then suddenly the tests are failing and then we go to the productive code. This is the back and forth, back and forth process is actually the main essence of the test TDD uh practice. So it is not a, not a I would say a theoretical topic, it's very much hands on. And we should really like to, I mean, we should all try to do at least once. How exactly it works.

And uh today, I'll show some uh I'll show a real life code example for my previous example, which is the phone number validation for, for explaining how exactly it works. Uh a brief history. So it is it is like uh not that we are uh talking about Edd very soon, I mean, or very recently, it already originated in 20th century. And initially, it was named as a test for development. But in 2003, uh Mr Kent Beck who is an American software engineer, he actually coined the term as test driven development stuff. So he is the person who wrote many books on that. And there are also uh great work by him on this, this area. Nevertheless, let's move forward. Uh But from the history, we have the agile connection. So, so why people always t this two word together agile and TDD? Because Agile tells us that um every requirements are changing constantly and we should be able to keep that development up so that we can provide the Softwares according to the need. So it is called the incremental development process. It is a methodology. It is not that uh it's a, it's a one time thing and one project is done that it's finished. It is a practice like, like, like we do many practices in our life.

For example, we get up every day, we brush our teeth and so on and so on and so forth. So this is also a practice that we also follow in terms of software development process. So what TDD provides in this agile uh picture, it actually provides a quality development technique that is when a software is written or the the way software is written, how the quality as should this is a technique always, I mean, when it is uh supposedly to be used in this uh agile mythology, but all the developers are not always all the time doing that, we will see why and why not.

Another point is like uh the test case analysis should always be done before the writing of the test cases. I have shared, I have showed a small uh uh pic picture of a penguin. Uh He is Kowalski, if you know the, the um animations uh movie Madagascar, he's also a character from the movie. So he is always and doing the analysis. It is a very, very crucial part when we are actually writing the test cases and talking about the test case and so on and so forth. Then um w when we are talking about agile, always, we are thinking in a, in a way that how we can produce a minimum viable product with, in with a sprint. So when I talk about sprint, I talk about a framework, for example, Scrum or Kanban, etcetera. So it is always like to provide a software which is uh doing the happy path and uh which is using the TDD. And um it is a great uh approach to actually uh uh see a problem and provide a solution. Working software is a primary measure of the progress. And the TDD is actually provides the incremental developments which always goes hand in hand with a child. Here.

Um This is the point where we would like to go for uh in depth like uh a turning point where we will see soon the uh real life problems and how we actually write test cases. So here moving forward the practical approach. So the rules, there are rules. This is something like we should follow the guideline and then we jump to write the the test cases. It is not that always we think OK, this is the test, how I should write it and blah and blah, we have rules. The first rule is we have to write a single unit that is describing the aspect of a program. For example, I mentioned phone number validator. We are not talking about the whole project. We are talking about particular feature that feature is is provided or co uh covered with unit test. So here we shall start writing a unit test when the test is failing. Obviously, we have not written any productive code, the program will fail. Now we will just write enough code to pass the test, then we will refactor. This is also known as red green refactor. You have, we have seen many um many books and many posters. That is what is red green refactor. That means when we write a test, it will fail, we write the productive code it will pass. Then we go in a refactoring mode to provide more functionality and better test coverages. So this is like a so uh back and forth approach and it follows in a circle.

Now, obviously, we have to repeat so that we know how exactly it is happening. Let's look at a real life problem before that we have to use some tools to pro you to uh to write test driven development. I am using Java, you can use any language, but I have seen that most libraries are available for this unit. Test cases with Java are really good. For example, Moto is one J unit five is one. I'm using intelligent idea because I feel uh it has a lot of great uh you say test or library support and the overview is really nice and look and feel is nice and a lot of cool tips and tricks are there. I'm using spring per project with Maven right now to show you the example you can use any other will do like gray and et cetera. So it is up to you what you would like to use. But uh this is a demo where uh I'm using this, these options to show you right now. And uh just let's look some look, some real quotes here. So what you are seeing, you are seeing an application which is, which has a name TDD Java example application which I created with spring boot and it has a bare minimum, just a structure, nothing is written.

So this class you are looking at it is the main class of the springboard application. And uh now going forward, I will try to show you how we can start uh the uh practice TT D here. So we would like to start with the test class. So as I mentioned that I would like to uh uh cover the phone number validation function. So I have created a package in this, in this uh project structure. You can see both the productive part and the test part. So you see the productive part is written in the main and the test part is written in the test sub package. So this is a clear separation for any maven projects. If you are uh starting on, then uh I would like to read a class. I have created a uh selected a name called phone number validator test and now my class is ready. So here I have written a goal because it gives me a clarity, what I should, what I am going to do here. And uh my goal is to create a phone number validator function. So now what I shall do, I shall write a method which is annotated with test here. The test annotation is coming from the J unit library. So you see the import or J unit Jupiter API test here. Um You see that I just uh mentioned only a name that test underscore for number validation function. It has nothing. So ideally it should pass because I haven't provided anything at all.

As you see when I am running the application, I see the test is passed. Now, I have to obviously um this is not my goal just to write a blank test. I have to provide a phone of validation function. So how to do that? I have created a phone number validator object. So here you see that there is no phone number validator at all present in my project. So I would like to. So either in this situation, my test is failing because you see there is a red mark in intelligent, is telling you that no, nowhere it is present. So my test is failing here. So now I would like to create the validator class where I should create I should create in the productive section which is a main. So you see the target directory is very important here that you should choose the main, not the test going forward. I have a phone number in class but it has nothing. So my co should do nothing. I mean the the test is actually doing nothing now to move forward. What I should do, I should refactor the test and to provide the validation function and try to see whether my test is passing or failing. And you see that I have created a setup method to pro provide um a new instance of this object.

And what is actually doing the annotation before each it is actually setting the stage before running the test. So every method is annotated with test, it will look where the before each is located and it will try to get the settings configuration blah blah and then try to run the test. So here I would like to create a new instance and then write to run the test. That's the reason I created a new instance in the setup method. And this is a general general um standard that you should write uh the name set up. It's not like uh whatever configure or et cetera. So this, this is a very um up to the date approach, like you should write that way, then oops, then um I would like to factor the test method what I should do. So the general process of writing test is you should provide a test data, you should do something that means you should call your productive method and then you compare the results. So here the the the good practices that are like you should like uh do give when, then this is a very uh it would say cool approach to write or structure this test method in that way given when then approach.

So here, I have given a phone number, test data, whatever be it. Now, in the when section I would like to validate the test data. But when I'm calling the function validate, you see that it is red that in intelligent cannot uh recognize that what exactly the validate is for. So it is throwing an error. So what I should do now, I should go to the productive class, which is a phone number validator class and then create this method. So here am I I have done that. So I have by default, set it as written through, you can set as anything like uh as I have, I have written type true or false, you can set anything. So here as my productive code says, whatever string I'm giving in this function I will return through. Let's look at the test class and see whether this test is passing or not. I'm sure it will pass because I have, I have nothing uh concrete validation written here. So like you have seen that I have added the one part, now I have to add in the then part. So what I'm writing in the then part like I'm just trying to get the actual result and expectation.

So here this is a very uh standard notation to, to get the method or the variable name like here, what I have used is actual actual uh should be used where you are expecting something and you are, you are, I mean, not expecting you are trying to measure the data, the result.

So you call the actual when the productive method is actually calling something, I mean giving you some data and then you are asserting the actual to test the data. So the assert uh uh I mean statement is actually trying to get whether the act is true or not, but in this case, it will be true because I have nothing in the productive code. So I will run the application and then my test is passing. OK? Now this is not an end. Our main goal is to create a phone number validated function. This is not that this is uh something like a structure or a or a base I have created. Now what? Now I have added a functional functionality which is the phone number should be greater than uh the size of the phone number should be greater than 10. If not, it will return false. If yes, it will turn true. Now let's look at the existing code base, uh existing test code and try to understand whether it shall pass or not. So according to my test case, if I run it, it will pass because I have already given a phone number, which is, which is more than 10 characters. So it's, it's totally fine here but it is nothing in here.

So what are the good thing and bad thing for, for, for way of, of writing this this method or this test cases, which is, which is we are not here to only checking that which are passing, which are, I mean, only passing here. So we are here to see how many, I mean, what are the invalid test data and how we can mix and match data and provide input and then test. Now, I would like to provide some invalid test data. Let's say my my test data is having less than uh length is less than 10. And what I have done that I have, I have um uh added uh invalid test data. I have added a we section where my actual test data are actually validating. It is the uh method. Uh The variable name is actual for invalid test data and then I'm here asserting it. So what will happen? Ideally it should also pass because I'm asserting it to fall. That means it is correct. My test is correct that it is uh not uh a valid phone number. Let's see. Yes, it is passing. And now we are in a stage like we shall always, we shall always go to the productive code and refactor and then come back to the test code and try keep on trying running the test so that we can get the uh idea of how exactly the code should look like and how the method should look like.

It is not that we are just writing, I mean huge set of functionalities before in the in the productive class and then try to mix and match test classes. So we are always here not to write garbage code. We should follow the clean code principle that how much is needed we should write that nothing extra. So it will help all developers to save their time to debug and whatever manual testing and everything. So here it is a very, I would say um effective tool to, to start with uh development in, in this way, let's move forward now. So now I would like to do something like I have given a, I have given a a new um data data which has uh something like I have, I would like to see the whether my productive code shall handle uh this kind of data or not like without country code. So I have not given any country code, I just give any simple data. Now, what I'd like to do, I would I have done when that means what my um uh phone number validator should provide me as a result and then I shall assert it as a true. So as of now, I expect it should be also true. That means it is valid, but actually in ideal case, it is not valid. That is our failure that this in this situation like this.

Uh whenever this this point like um uh wrong data is getting through, that is a bug here in bug in our code. So to solve this case, we would like to go to the productive code and write the clause where the uh phone number is starting with, let's say plus 4 9 example. Just a simple example. If yes, then only I shall pass, otherwise not pass. Moving forward here. I have just said that when I have a phone number which is uh not started with plus 4 9. So it shall uh provide um me uh I would say the validation which is false. OK? Um What I can say that I missed to add one screenshot where this uh this one that uh the assert uh the without country code is true is failing. So here, uh the point is what I missed that when I run this code, I will, I will see that my test cases are failing and to make good or to make it pass, I have to go to the productive code and add the functionality. And then if I go to the test cases and then run, I should be seeing that the code code is getting uh uh executed properly when without any error. So um maybe I will update my, uh I would say PPD later on and can share.

But this is the goal where we should do that. Keep on refactoring the productive code and trying on test and then backpack and forth option. So this is the main essence of, of the TDD in the real life. But I would say this is a very, very simple uh program. I'm pretty sure that you are doing or anybody has the experience has a lot of great uh I mean, um features and everything. So I would be really happy that, yeah, if you could share your experiences, writing uh test classes and stuff like that with a more complex structure and so on and so forth. So it will be great discussion for us here in a, in a I'd say in a software development um area. Nevertheless, so now I would like to share some prob, I mean pros and the cons for DVD. So let's start with the pros which is like uh it is a very efficient uh tool to find errors and the problems. Um The thing is like as I showed that the phone number has uh without country code, I know that my code has not uh I implemented anything. So I know this test should fail. This is the fail fast approach.

That means we know the test is failing, I understand. So now I will make the better code so that the test is passing and write just enough code, not uh super extra or stuff like that. Um For, for doing the DDD, it is required to knowledge for internal software under test which, which is beneficial. And uh it is actually for thorough testing, we know that it helps us always finding hidden errors and always say that like whenever we have this kind of validation methods, it's really, really helpful for all the developers who are following this approach because we think where the problem occurs, where will the validation fail?

So that is a great tool here. Now, um programmer introspection is something like uh always we as a programmer, we look for when we have our detective eye in terms of debugging the code, writing the code. But nevertheless, here we are always uh providing a lot of great introspective view. In in terms of the TDD uh perspective, it always great tool to optimize our code. That means I mentioned that we are here a fan of clean code, not extra code, we should write and stuff like that. And uh there are internal knowledge is required so that we should provide the maximum code coverage. Now, I'd like to share some negative part of the TT D which is that um who as a developer, let's say New bee who has joined the team, he or she needs to provide or I mean, needs to get the code access, then it requires high level knowledge of internal architecture, how exactly a software is working?

Then the test cases are really tightly coupled to the implementation details and then sometimes it fails for like unwanted test failures when the code is reflected. And also that it is might, I mean, the co the negative part is sometimes it is uh mm missing the feature, that means unimplemented code has not been found or seen in this approach. So there should be somewhere uh good documentation. So we can provide that these are the found use cases are provided. And then people can actually start this uh follow this TDD approach. And then then coding now moving forward, I would like to share some user survey. That means what people think about this approach and how it is uh how much accepted in this approach by a software developer community. As you see that uh this TDD approach is actually uh I mean, is um having a lot of matrices that means white boarding, like how we are thinking to draw a use case, something like that, how the diagram or uh there are a lot of um tools which are provides diagrams uml tooling and stuff like that.

So how it can help us then text based approach and then electronic approach and then modeling tools. So every, I mean, every aspect it has there its presence and uh in my experience, I have seen that not everyone is very much fan of uh TDD. There is a reason is like they, I mean, as a developer, we would would need to think everything first then write the it is difficult. I mean it is difficult sometimes but I think that it is great opportunity to start. Why not? Because we will face no debugging, debugging at all. That means normally when a software is running, we have bugs. So always we need to debug the software to find the bugs and stuff like that. So here we shall like never, never ever find a bug if we try to follow this approach. And it's really difficult at beginning. But I I can share share from my experience. It is very beneficial when you are already hands on. And initially it is tough and I'd say you should take guidance and you should read proper documentations. And maybe you are, you, you can share, look some videos and stuff like that. I have some uh resources and uh books to share. So they are uh there are two books I would refer. First one is uh test driven development with Java. And the second one is the by the inventor who is Ken back.

And these two books are really good, but sometimes books are a little bit boring because they are all we have to read and read and then code. But nevertheless, uh there is a video code very helpful uh which is clean code with Java. Learn simple design, Andrea Turning and TDD, which is uh done by in 28 minutes official in Udemy, you can get it. It is not free unfortunately, but you can get it in €10 or something or, or any, any uh any other currency when it is sale because it is really useful. Then the blog II I followed this blog from Martin Fowler, he's a like renowned software engineer and uh he has, he has done a great work in this software engineering development perspective. So you can look up this kind of resources for more information and stuff like that. And if you like to uh like join me uh in any discussion with you, I'm really happy to happy to help you out. Um And I'm really open, I am sharing my um github and linkedin um addresses so that you can, if you would like, you can connect with me and for the future. Yeah, references. For example, this is my linkedin profile. This is my github profile.

I'm sharing just right now. And uh yeah, I'll share this presentation and this code based in meet after the conference. And uh yeah, if you feel that uh there is a, yeah, you would like to connect, you can connect any time I will be really happy to join you. And now, and now it's uh your turn and, and uh I will be answering all your questions. So, first of all, it's the stage is yours. If you have any questions, let me know and how you feel about this presentation. Also, let me know if you feel that uh there is uh improvement chances of improvement. Also, please let me know. I'll, I'll surely uh work on those topics. So, yeah. Now the stage is yours. Please let me know your questions. I'm looking at the chat and uh unfortunately I can't see any questions. So yeah, I will wait for some time. Yeah, this is awkward silence. I believe that everyone is very busy or maybe looking at other other conferences. I'm sure there are great conference topics and stuff. So um just, just, just you can just put like at least some, some comments that what exactly you felt. Yes, Zala, you can get the recording for the session. I think it will be available in a month or so because there are a lot of sessions and uh the Women Tech Network team, they are working really hard to provide the recordings via youtube link.

So it is public, for example, you can go in the um women Tech Network youtube channel and you can find the last year's uh old uh conference topic. So this is a youtube channel. You can go and you can, you can see there are there are already uploaded sessions. Thank you, Marcia. And um I would uh yeah, I'm really happy that you uh you felt that the topic is really clear to you. So I if you, if you like, you can connect or um yeah, I'm really happy if you feel that is uh this, this topic and my presentation is useful for you. It's really great. Thank you, Zella. Thank you so much for your comment and thank you Rimel. And uh yeah, it's very nice to see you joining my session and yeah, it's, it's really nice. Thank you very much, everyone.