JUnit In Action With Catalin Tudose

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Automation Podcast. We're all getting together to learn more about software testing and automation with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Catalyn Tudos, all about the book Junit in Action, as well as some of his pluralsight courses. Catlin has a PhD in computer science and as a Java and web technology expert with over 20 years of experience in it, and I believe 15 years of that is as a senior Java developer and technical lead. And really cool. That, I think is really cool. He's also a professor at the Faculty of Automation and Computers in Bucharest. You don't want to miss this episode if you do any type of automation. Like I said, he's done pluralsight courses, so we'll probably touch on bdd, the Java Test library td. So you don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey, Katalin.

Welcome to the Guild.

Hello, Joe. Nice to meet you. Hello everybody. Catalina Dosse here.

Awesome. So, Catalyn, before we get into it, could you just tell us a bit more about yourself? I gave you an intro, but is there anything I missed?

Thanks for the introduction. I confirmed it and I can detail it a little more. So I'm currently acting as Java and Web Technologies expert at Luxor, Romania. I am based in Bucharest. This is the capital of Romania. Here I am following my activities. I am conducting and developing courses for Luxo, Romania. I conduct courses at the faculty. I conduct courses at the Faculty of Automation and Computer Science in Bucharest. And I'm also involved in developing courses for Pluralsight. And now I am writing this book for Manning.

Very cool. So I definitely want to get into the book G Unit in action. But before we do, first thing that comes to my mind is as I research you on the Internet, it seems like all your pluralsight courses are around testing. This book is on testing. You're working as a professor at the Automation Computers. Why automation? What makes you passionate as a developer about testing?

Testing our software is extremely important. You cannot imagine having a software that is running.

And that it is not enough tested. You have to have the safety, you have to be aware, you have to be sure that that software is correctly working. You need to have the trust that it does what it needs to be done.

So all software in all domains need to be tested. That's why we may say that testing automation is a very important and covering topic. It covers many fields of computers, many fields of software development. No matter if you are developing software in Java or in C or in net, it needs to be tested. No matter if your software is designed for financial applications, for automotive, for telecommunications, no matter the domain, it needs to be tested, it needs to be reliable software.

So I know you're working on the third edition of Junit in Action, but I assumed you've been working on it from the beginning. But in our pre show you said that's not the case. What got you involved in the G Unit in Action third edition rewrite?

Okay, probably I should tell something more here that will bring us to the book.

Sure.

During my last about 10 years of developing in Java, developing software has become harder and harder and you needed to have this safety. You needed to know that.

Your software is working fine and the need for people was increasing and increasing. If you are doing your testing manually.

Then you have to spend a lot of time and a lot of resources. And what is even worse, you will not have 100% safety that your software is working well. Fortunately, some part of the activities can be automated and I have been involved in doing this and implementing this in the projects that I have developed.

So we have introduced automation testing from the basic unit testing up to integration testing and acceptance testing. Then based on my experience, I have started to get more and more research and I have been involved into the development of three courses at pluralsight. All these three courses are related to test automation. It is TDD with Junit 5, then BDD fundamentals, then implementing a test pyramid strategy with Java. All these courses are related to test automation, from the unit testing, which is at its ground, to the acceptance testing which is related to verifying if our software is addressing the user needs. I have started to work on the Junit in Action third edition in this spring. I have put there my already existing experience and it is a very large covering book. I was saying that it is the third edition and since the second edition which has been published back in 2010, a lot of things have changed. First of all, we have introduced Junit 5, which is a big step forward compared to Junit 4. It has come with a lot of new things. Then some frameworks have become more and more popular. I am talking here mostly about Spring and Hibernate and our Junit in Action third edition book is dedicating a large part of it to testing Spring and Hibernate applications. Then I have added some special chapters that are dedicated to test driven development and to behavior driven development. These are very modern techniques. They are in use or will be in use by many projects around the world. There is also a tendency to educate the people and the teams that are involved in software development so that they can adopt test driven development and behavior driven development.

So I guess before we dive in, it's a little bit more to some of the points you brought up. For folks that don't know, say they've never even heard, maybe they use a different programming language. What is Junit?

Junit, to provide the definition, is a testing library for Java. If you haven't used another. If you haven't used Java and you have used another programming language, there is no problem about it. As I was saying, all programs need to be tested. All software needs to be tested, no matter if you have developed it in Java or in some other programming language. And we have to say that Junit is part of a larger testing libraries family. It is called Xunit and there are versions for this library for programming languages like C or. Net. So no matter if you haven't interacted with Java, you will find some common ideas and some things that you can learn from Junit.

Maybe it's just my experience, but I worked for a large company and the developers really didn't seem to understand unit testing. So is this something that a lot of people get confused by? Like what would you consider what is, I guess what is classically considered a unit test.

Classically a unit test is something that is testing small piece of your code, a unit. That is why it's called unit testing. When you say unit testing, you are thinking about testing a method or a class in isolation. So you make sure that you have a class with a few methods and that their functionality is well tested and in an automated way. This is the essence of the unit testing and this is very ground of the testing activity. Because of course if you are developing software and you know that software is working well, but only isolated in isolation, like isolated classes or isolated method, this will not be enough. You will need to do more. First of all you will need of course to do your unit testing. But then you will need to put head to head the classes or the packages or the or the modules. And you have to be sure all together they are working well. So first of all you have to make sure that they are working well in isolation. And after that you make sure that the classes and the packages are working well in isolation. You are going to put them head to head and you are going to make sure that the modules are well integrating, that they are well cooperating in solving your problems.

I guess another confusion is.

What makes for a good unit test. Should everything have a unit test and do you need to write a test for everything you do?

The recommended way to work nowadays is that you should have unit test for all your software. Of course this is not always possible for various reasons. Maybe you have inherited some old software, it may have hundreds of thousands or millions lines of code and it will be very tough to start to unit test everything. But if you are joining a new project or if you are starting to add the new separated modules to some existing project, then you should always think about testing. You should always ask yourself, how can we make self testing software? Because even if you spend some time in some early stages of your development, this will strongly pay back at the later stages. You will diminish the debugging nightmare. You will have the safety of a much better software. You will reduce the many complaints from the side of the customer. You will have the safety of having done a well working thing.

A lot of developers treat it like or act like it's a pain to have to write unit tests, but I think you brought up some good points there. It's really to help them, right? It's a safety net so that they have confidence when they do refactor code that they have tested to help them if they broke anything. And also like you said, debugging. I guess it helps with debugging later on down the road, which can be kind of tedious if you don't have proper unit tests in place, is what it sounds like.

Debugging can be a nightmare. Every developer with at least a little experience does know this. And with unit testing you are going to strongly diminish this nightmare, even bringing it close to disappearing. When you will find a bug, investigating and understanding where it comes from, maybe some very tough job. But if you will have good unit tests, those unit tests will have the capability to show it right from the beginning. Hey, here you have a bug, you have changed something and this is a unit test that was previously working and now it is broken. So first of all, you will know about the bug very early, right from the beginning, right from the moment when you have introduced it. Then the unit test will show you will tell you exactly what has happened and where has happened. It will say, oh, I was expecting Here the value 0, and now the calculated value is 1. It will tell you exactly what it was expecting, what it has been provided and where. So it will provide you the best information that you need and it will be localized. It is happening here. It had to be this, but unfortunately it is that and you will be able to go directly there and try to fix it.

Very cool. So it sounds like even after unit testing, a developer's job's not done. You brought up some terms like TDD and bdd and you actually have a course on pluralsight called Implementing a Test Pyramid Strategy for Java. Where does unit testing fit into that test pyramid strategy?

Unit testing it right at the ground of the test pyramid. I was saying that first of all, you have to make sure that your units, meaning your methods and your classes, are working well in isolation. If they are not working well in isolation, it does not have meaning to put them work together. So first of all, we'll make sure that our classes are working well by themselves. Then, after having made sure about this, after having built the very first part of the pyramid, the ground of the pyramid, we may think about putting more modules together. So unit test is at the ground of our pyramid. And then we can put a few modules together and we may think about integration testing. We have well working modules, we have well working classes. Everything is safe in isolation. We'll try to put them together and see how they integrate, how they interact.

I think a percentage I heard, I don't know if it's a real percentage that people should aim for is 80% of their code should have unit test. Is that a general rule of thumb that you agree with or does it all depend on what you're developing?

This is a discussable thing, first of all. Indeed, I have mostly heard about this 80% requirement of unit testing. And in the projects that I have been taking part, I have received the requirements about having 80% or more of code coverage. But this is not enough. First of all, you may have some problems within the remaining 20%. Then even if we have 80% of code coverage, you do not have the safety of the quality of your tests. So you may have 80% of code coverage, but your tests may not be good enough. And the test, if they are not good enough, they may hide some bugs even if the test passes. What I would think to make even a better and better software would be two things. First of all, people should try to get even more code coverage more than 80%, even more than 90%. From my experience, the step from 80% to 90% is pretty hard because you need to do things sometimes artifices in order to ensure this higher code coverage. Then getting upper to 90% is extremely hard. Sometimes it is not possible to get closer to 100% but you should still keep in mind try to do this. Get as close as possible to 100%. Then we have to ensure the quality of our tests. We may pass by there, we may have code coverage, but in fact we may not test everything. And here comes some other technique that it is called mutation testing. There are libraries that.

Are able that during the execution they change the tests and they make sure that if they change the tests, those tests will fail. Because a well written test, if it is, if the code is a little changed, the test should fail. Some projects should think about introducing this. Even if it is an effort at the beginning, even if it involves some technical knowledge and some convincing of the people of adopting it, it will strongly pay back. Within a few months you may have a much better product, a much better software. And on the average and long term, you are going to get very good results.

I've heard a lot of great things about mutation testing. What library do you use for in Java for that?

For Java the library that is used is called PTest PI Test.

So you just tell us a little bit more about mutation testing.

The idea behind the mutation testing is that you have to make sure of your test. You have written a test and it is running against the code and let's say that it is green and this library will come and change a little bit. The code that is tested, it will reverse some if condition, it will do something minor there. But this something will have an impact on the execution of the test. And if your test has been successfully run against a code and if your if your test is a well written one, then when the code will be changed by the mutation testing library, Ptest in this case, the test will have to fail. It will show that if you change your code with changing some condition, the test will fail. That will mean that your test is well written. That will mean that your test is really considering that condition that it is changed.

Do you have a chapter of this in the updated version of Junit in action or do you plan on having a chapter on mutation testing?

No, mutation testing hasn't been included here because it is.

A concept by itself and it should be covered in some separate work.

So I just want to get back to Junit and Testing Junit in action Again, you did mention Junit 5. And are there any new features in Junit 5 that helps with testing?

There are a lot of new features that help. First of all, Junit 5 is coming with fully new architectures with a modular architecture. What has happened before Junit 5 for Junit 3, for Junit 4, for example, you had one single file, one single jar that needed to be included into your project. So everything seemed to be very simple. But as long as everything was within one single jar, everyone was using that jar, you were using as a developer that jar, the builds were using that jar, the IDEs were using that jar. And the problem, one problem was that the jar was not designed in order to interact with all These tools and IDEs or build tools needed to get inside the classes from the JUNIT JAR file and do changes by reflection, get information by reflection. And this is not the nicer thing. So the idea is the build tools were tightly coupled with the Junit jar file. Now Junit 5 has come with a different and modular architecture. It is divided within three modules. Junit Platform, Junit Jupyter and Junit Vintage. These modules provide the possibility that the IDEs and the build tools to interact with with Junit through a dedicated API. So these tools don't need to get their hands inside the internals of Junit. And this is suddenly a big advantage. The interaction between Junit and all these tools that are using it is much, much better. Now we may say that in fact the popularity of Junit have become brick for its development. It was used by everyone and everyone was getting inside it through reflection. Now with this new modular concept, the interaction between the still very popular Junit and the tools and IDEs around it is much simpler. Then Junit 5 has come with new annotations and with new you can nicely display information about your test using the display name annotation. You have new assertions and new assumptions. You have the new concept of nested tests, test inside tests that will provide you some nice here or he and you will be able to easily follow the logic of your tests. It has come with repeated tests. With dynamic tests. You have the possibility to parameterize your test in a few ways. So the ground of JMET 5 already provides a lot of new features.

Seems like a major upgrade for sure. So people should definitely jump on it.

Absolutely. This is a major upgrade. It comes with a lot of big advantages. And it is not so hard to be adopted within projects. It is not so hard to be understood by the developers. The average developer with some minimal experience in Java, let's say at least two years in Java, will be able to quickly adopt the new features of Junit 5.

Before we go, is there one piece of actionable advice you would give to someone to help them with their Junit automation testing efforts? And then what's the best way to find or contact you?

Okay, let me say a few things about adopting Junit and in particular Junit 5. First of all, people should be aware of the big advantages of adopting automation testing and Junit 5 is nowadays the ideal tool and it is not hard to adopt if you have some average experience in Java. I was saying about let's think about two years of experience in Java, you will be able to understand how to work with Junit. Then you shouldn't be afraid of the time that you will have to spend at the beginning in order to write your unit tests or to cover your project with tests. Because even if you spend some time, especially at the beginning, you are going to recover it by reducing the debugging nightmare by better understanding your software. Because as you are testing it, you are going to better understand it and you will feel much more comfortable with developing your project that is not tested, will spend a lot, a lot of time in the maintenance phase. You will have a project arriving to maturity and you are going to get more and more and more bugs from the side of the customer and you are going to fix something and it is not impossible that when you are going to fix something you are going to break something else without knowing it and of course without having this intention. And this is of course dangerous. If you have adopted automation testing, if you are working with JIT5 and if you read and if you write good tests for your software, these dangers will greatly diminish. So you are going to be fed back for adopting this technique. It is an extremely useful technique and it is not so hard to adopt. It is mostly about the habit and about having the consciousness about its importance and about introducing it within the project. Then if you would like to contact me, I am easy to be found on the websites of Manning. I am easy to be found on the website. You are going to discover more and more information about this book that is currently in publishing. More and more chapters will be added to the Manning early Program Access version and you will also be able to if you would like. You will also be able to follow my courses on pluralsight and to contact me through the pluralsight website. If you would like to directly contact me, you can easily find me both on LinkedIn and on Twitter. Just look for Catalin Tudoce and you will easily find me.

Thank you Katalin for your Junit Automation awesomeness. The links to everything of value we covered in this episode as well as a special test guild 40% off discount code for Junit in action. Head on over to test guild.com a lake automation283 and while you're there, make sure to click on the Try it for Free Today link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And if you haven't heard Already, Automation Guild 2020 registration is now open. You don't want to miss this event. It's the largest online conference in the world, dedicated 100% to helping you succeed with Creating Automation Awesomeness. Our goal is you learn a tip, tool, technique or best practice you could put in place in the new year to help you accelerate with your automation efforts. Head on over to automationguild.com and register today. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe and my mission is help you succeed with Creating Automation Awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.