Ixchel Ruiz 0:09
Thank you, thank you Melissa. I’m really happy to be here today of old days. So when, when Malisa told me about this event, I was super, super excited. And I only wanted to put the title spooky connections, because I am going to talk about testing. But we will build up a little bit to topic until I reach. So I’m sure we can fire at mustard on LinkedIn, Twitter, and you have a champion, I collaborate with a wonderful foundations, and I loved everything about software, as Melissa said, the human part and the technology part. That’s what makes me very, very passionate. And Melissa didn’t miss you. But we actually wrote a book together DevOps tools for Java developers, so they have collaborated in so many different adventures, and Elisa and I, and technology is just one of those step Hunter DevOps, and it doesn’t have to be scary. And I agree, because my first thought it was like, awesome today of all the days, because for me today is that the the mortal sea, and boy ready for it? And, and if you know any Mexicans, and even if you saw Coco, you know that, that, and what are those Halloween is not something scary is actually something that we appreciate we value. Inspiring and good. So really scary, is not I mean, when I think about the most recent or the batch, I usually think about fluffy and cute and nice. But then I remember we’re talking about software. And I was like, do we have monsters under the bed in software? And yes, and then rush back into my mind. And yes, and there’s the monsters that we have in software development are not the fluffy, cuddly nice monsters, and some of them are not even vessel.

Ixchel Ruiz 2:33
So I feel exactly like that, like, Oh, my goodness, this session is not going to be so happy on on flowers and candles. But let’s take a look closer to our monsters. There are a lot of them. And at the beginning, I thought, well, it’s going to be only one or tweet software development. Let’s talk about our monsters and the first monster of the day. Or of the night it’s going to be time and numbers. I know what you’re saying I show for crying out loud. They are an infinite number. So of course this is difficult. But then our problems are even when we count to 100. Oh, yes. So we don’t have actually this cubes there. But anyway, let’s continue second monster security. Oh, well, I’m actually not going to go into monsters, but I just want to let you know the gravity of the monsters that we are high or under our bed. But do you want a little bit of details about this particular one? Well, we had 18,000 government entities affected and most of the 514 companies and nine federal agencies and more than 100 companies were exposed in the first attack of the first wave of attack and this actually created the environment for all other really important attacks, for example, in the pipeline and use fuel pipeline and the Irish health service system and more. So it was a big it is still a big monster under the bed.

Ixchel Ruiz 4:37
And let’s talk about format measurements. Yeah, the Ariane 5. So that was an error that cost in that particular second 370 Millions because we had an integer overflow. So for satellites 2600 pounds of the clusters. And in general, their Ariane 5 turns into smoke on June 4 1996. And see in one of the reports of this particular malfunction, it clearly says this could have been prevented if had better testing. Let’s talk about language because language is there a lot. And it’s also a very easy thing to do. But there I mean, obviously, I’m talking about translations, but not only translations, why the we sometimes even prevent the small things like do you want to cancel your subscription and you will cancel and cancel. So sometimes our design our way of managing operations, language and intentions to our users is not the clearest one. Next monster, we were already there usability? How much do we make our users feel welcome and understand their different necessities? Well, for this, I didn’t even show examples. Because if I’m honest, even my own personal site is not 100% fully accessible. And this is why there are several reasons and most of them are going to be excuses. So no real good reasons.

Ixchel Ruiz 6:35
And then, the last and not the least important problem is generative AI, what the future will bring us. So there is a lot of monsters here. And by the time I like this, because they are really fresh. In my mind, these are the issues that I’ve found day after day when I was a consultant, I was a little bit depressed, not the objective of this session. So it was a shell, this was not the objective, I mean, improve this particular session. And if I’m exactly like that, so how do we actually improve the spark gives a point I was feeling already a little bit depressed. And that’s not a good feeling for anybody. Nor for developers. No DevOps engineers know anybody. But then I remember, this is not exactly about software development. This is more outside DevOps, DevOps, a strategy, or what our workflows, it’s this is, this is not spelt. So at this point, we haven’t decided about formats, we haven’t decided about languages we haven’t decided is there, like this is not the focus, of course, it’s part it’s part of the software development cycle. So I said to myself, well, probably here, we don’t have as many monsters as in software development. But again, that was not the case. And the most frequent cause for confusion, degrade build to fail, is due to test that do not pass. So again, I went back to the other side testing, this is going to be totally important. No matter if you are a software developer, you’re putting you are a DevOps engineer, or you are in any part of the spectrum. And you know what, I refer a spectrum, because in this moment about how do we build software, we are either fulfilling the roles of so many different people, or every single people has to know a little bit of all the different activities and roles and operation and tasks and responsibilities of many sections of the software development cycle.

Ixchel Ruiz 9:14
So I not think of myself as just a software developer, not only a DevOps engineer, so I have all those two main job roles. So testing is really important. But again, test are not the same. They are not created the same. And when we are thinking about creating our strategy, like how much effort do we have to put to unit testing how much too permissive penetration testing how much forward contract testing from consumer to provider, how much you do integration test. Testing. And you will, because creating testing tests and test suites is expensive. Writing Test, it is expensive. So when we have our set of test, we have to balance how we execute them in the time, not only time constraints that we have for executing certain tests. So it’s not only creating maintaining the mission, but also during runtime, are these derived tests that we should be running a specifically for this operations? Are we actually modeling correctly what we should be testing. So when we want to create a good testing strategy, from the decision that we have already created from our universe of tests, either, if it’s a pyramid, it is our kind of shape, because now we’re even asking the right shape for our tests. Should we have more unit tests that integration test, integration tests are very expensive. So that’s why the we don’t have that many, any integration tests actually are linked to complexity of the software or the interfaces that we have. In the past, when we have to mock a lot of services for an entire class for a single class, we said to ourselves, this is clearly insane. It’s so difficult to create a microscope for it, it’s going to be more expensive. So we created or we, we focus our efforts in creating the unit test and the functional testing. And we said this dest of this will give us the quality that we’re looking for in our software. So this is kind of the conversation that we will take us into the rabbit hole. And because I won’t give you a percentage right now and tell you well, you will have to have 60% of unit test at a 10% of functional test key of 5% of integration tests, but don’t forget about your API. So add some testing there. From the consumer point of view, if you’re creating your API Interfaces, create some producer kind of testing. So your consumers can can always download that password, check that your specification is still in order. So I’m not going to go in the action. Instead, I’m going to tell you a story. And I think it’s a good story, at least, my skull says spaces.

Ixchel Ruiz 12:59
So this is a story, of course very close to where I am right now, more or less close. And the day it’s September 2008, it was Geneva Switzerland, it actually was a very sunny day, but for the for the details of our story, it was not really it was a very cloudy, sad and cold day in that particular place in this room. And as you can see, there is a bluish kind of queue in front of it where it says that is the accelerating science etc, etc. Right? So the actual depot. And this year was amazing because finally through so many years of building this particular international facility to investigate the god particle was up and running. And it was overrun and get everything was awesome for 36 hours. And then poof, literally poof. So what actually happened well in the first picture that the appear very good. The first and the second one appear very fast. But anyway, the first picture as you’re probably right, you will see how the rink is created with all this this this dimples with the sprockets. And the second picture is what happened after that moment. So, after a few hours, a few days, there were several reports. What happened, why it happened? What was the problem? And turns out that well on the bright side, there were enough pieces to replace the damage. On the brighter side there was only We’re going to take two months to fix it. On the negative side. Well, this is incredible big building for testing purposes. So their tests were up a notch. They were amazing. They were wrong, whatever they think on an every single segment of the of the people, so they have the rink. But this building was not big enough to hold to the polls at the same time, one after the other. So what do you think they didn’t. And you’re right, they didn’t take the integration, they needed to variation between the two titles. And this is exactly what made poof. So one of the things that the CERN learn is that they needed to to the integration between the two different ones to verify that the current was running as expected that the helium wouldn’t have it. And literally, it wouldn’t have exploded us, it was so strong, the explosion, that even the brackets were inside the concrete to hold this. The bowls were totally destroyed. So they learn and we learned that integration test, it’s very, very important. But not only that integration test, it’s has to be contextual.

Ixchel Ruiz 13:57
And one of the most interesting parts of one session that I attended at Google was when the head of the infrastructure team was saying about how difficult it was to text. And one of the big lessons that they learned, and one of the classes that they learn is that we need to test according to what is going to happen in the hands of our users. It does make sense that we test in the latest machines, with the latest operating systems with a system that works in the best conditions. If our users are not going to be there need to test very close to reality, but testing very close to reality. Well, it’s difficult. Why? Because it’s reality. That is hard. And in our case, testing very close to reality means close to the components, or how things are created. So let’s meet introduce one of my most favorite tools, and it’s going to be test containers. And why is this container so fantastic for me? Well, one of the reasons why testing integration tests is so, so difficult, so expensive. So that’s why we try to reduce the amount like natural This is a natural reaction from developers, project leaders, project manager saying, like you want from the things that are really, really expensive in terms of computer power in terms of time, in terms of effort, etc, etc. Let’s do the least amount of them. It was because we have so many moving parts in our current motors of we’re creating or integration, we have databases, messaging system, cache providers, and many older third party services. So creating the real thing is not only very expensive, we need licenses. We need to run them, have them in in actual good running system. So at first, we were actually a little bit risky, we would have resisted the idea to create as many editions as possible, because it was hard, it was difficult to maintain it consume a lot of resources. So discontinued this very useful firm. Well, first of all, it plays nice or you can create your own tests in different languages with very good support. I mean, I’m a Java champion. Well, obviously my first tool of choice is going to be Java but if you’re working with go Next.js, Python, Rust, Haskell, Ruby and Closure. This is something that you can start using when we start using containers and running programs and running our code in in testing scenarios at the beginning, because when you create In a container, you’ll usually have to expose ports things, things, etc, etc. So running testing containers, it was fantastic. It was only one one probably in your development environment, because of this conflict of the names and ports and cetera, et cetera. When test containers comes into play, they actually abstract all this information. And not only that, they actually added something that I thought at the moment, it was the most insane thing ever. And that was they kill, and make sure that we dispose of our resources in the right way. So even as a software developer, I didn’t have to listen to my ops team telling it shall you kill again, our machines, because you have so many some BS containers here, that well, you need to make sure that your tests are terminated properly, and was by I resorted to a batch command that will kill all hanging containers. But this was not manageable, this was not really a good thing. So once this containers created this very fitting idea of a term container that actually were overviewing, the running sequence of all my tests, and make sure that regardless what the example, or the exit code of my test was, it was all going to be taken care of correctly, and nicely. So it actually creates, understood destroy the containers really nice. And this is an example of, of how you can create containers, test more or less. Exactly, and you’re actually posting you some examples coming from the side of test containers.

Ixchel Ruiz 22:07
And I actually chose this one, because I’m not sure I’m gonna come to show you the typical ones where test containers shines, which is that choices. And of course, databases are really complicated. And let me tell you that second thing that why I fell in love with his containers in the service containers, when I was creating my own, like with Docker composed, what would happen, I will actually have to wait for X amount of random, literally random amount of time on the container was set up in the right way. So obviously, random way, should always create kind of very smooth sensation in all developers. So one of the supports that I love about as containers in the different various specialized containers is that the health checks, the waiting strategies, it’s all taken care of. So for example, when you are setting up your container, it is going to tell you like it’s going to tell your test, hey test, we are ready to go, we have created or started the database in the way that you need it for running your test. So in this case, I’m going to show you at our mock test container actually not expecting you to read the code. So just listen to my voice. No, no, you can actually read it. I’m going to tell you what is happening here. So the beginning we are instantiating, the wormhole container, we are actually using a mock config JSON. And you will see why didn’t love wire mock and this particular example, and then later on, we are going to in the should get album by ID, we’re going to use rest assure to fake a client. And we’re going to say when I request in a specific Euro, then I’m going to expect it to be correct status code 200. And in the body should include a value which is the ID of the album ID that I’m sending same album ID that I’m requesting. And then in the body has to have property cool photos. Nice, isn’t it? And it’s very easy. So remember that part when it says start my WireMock container with a JSON file. Well, this is the JSON file and as you see fit We’re creating this specific URL mock is as simple as this. You say, I want to create a mapping of type get that follows this pattern. This is one of the beauties of watermarks. Why would they also be used with Java. But in this case, we are, or at least the people that created this, this example, is creating just JSON for, for specifying what the URL should be doing. So let’s say I have albums, zero to nine with photos. And then in the JSON body in the part of the body, it’s saying like, with return, the ID that you’re sending, of course, and also create, for example, the, the specific URL. So now when the container is creating a type of WireMock container, it’s actually starting this container. And it’s going to use the JSON file to create all this mappings into the WireMock container. And when they turn on in the test, in this part of the tests, we are actually using it at the at the lowest level, we are going to return whatever we mapped in the JSON file. And, for example, leave late from on we want to override and a specific stuff or model for WireMock. We only need to do that. Now, whenever somebody or really asks for this particular URL, what are we going to return it’s a five contract. And then very soon new or even feature for test containers, which is test containers. So because I had an M1 computer Apple Computer at the beginning, we have some issues with containers in this apple check. So this set me back a little bit, but then when those containers creator that created this functionality. So now all the tests that were I was running, they could be running on the cloud. So no longer I had this problem where I had to do magic on development environment, it was possible for me to continue running my test, because they were not going to be executed on a specific hard word that I didn’t have enough control to solve or there were some limitations. And so I in this vein, very nice example that it’s on the test container side, we so obviously, it has containers we choose should at least give it by two, to create your very meaningful, very short, very easy, readable and reproducible tests. Also have a look of where mock up I have talked about wire mock with different kinds of examples programmatically based all the capabilities that record and replay running a standalone running leave it I need, I cannot say so much about this particular. And finally, rest assured because it will create your client calls so easily. So I show you three or more. Or my test tools here or my test projects, or my test libraries that I love so much. And they are magnificent, I cannot say more prices for them. So they are actually very, very good tools.

Ixchel Ruiz 29:08
But yeah, every tool is important. But it’s not a silver bullet. And that’s that’s great that no tool is a single bullet because thankfully, there are not werewolves out there. So I really hope that at least you had a new view on something, either of our old monsters under the badge. And for the next project. One of the first thing that you ask is, are we willing to spend some budget into accessibility to make the site accessible or our project accessible? However we do, we’re going to deal with dates and times and for months. What is our default programming You know, our default language, if you are creating a product that has to run International, like these questions that have created a lot of problems in our industry in our lives, and they continue to happen and happen again, hope that you had a sneak preview, or I created enough curiosity in you to try and see the new features. And that symbols are important part, if you have already used computers where Mock, and rest assured, please have a look at the new feature that every single of these tools have released, because at some test containers has created in almost half a year, and you Kubernetes slide module, so you can even test your Kubernetes particular setup. And masters, yes, sometimes there can be scary, but they are also a source of inspirations to improve during and to have better solutions for the challenges ahead. And as my session I hope you enjoyed this is how you can contact me must appear on our Twitter and LinkedIn. And to see what usually I have inside my Github. I love feedback. I love talk talking to people. How can I build this session? Because this is was the first set time I gave this particular session? I mean, I don’t get a lot of opportunities to talk about this particular day. And then so excited. So how can I improve it? What should I show what I shouldn’t show and say?

Melissa McKay 32:05
Thank you so much, Michelle, that was fascinating. Absolutely. Especially what you shared about the Hadron Collider. That’s a place I haven’t yet to visit. So on my bucket list for sure. Hopefully, on a day when failures like that is or not happening. Course. I actually never knew that about it. So that that was interesting. One of the early things that you said in your talk, you said you like CI tests are the biggest cause for failures in an in your CI builds, or a tests because of tests failing, sorry. And I just made me laugh. Because I know you just recently went through a time change right over there in Europe. So we’re about over on the US side, we’re about to go through that this weekend. And it just reminds me of a time when I had a bunch of very brutal tests that were reliant on time. And they would always fail, you know, at particular times in the month, and I’m just remembering, you know, it’s definitely not driving me absolutely insane. But what you really reminded me the most is that testing is not just a simple thing, it’s not something that happens after the fact or just by somebody a tester just sitting in begging on the keyboard. So, what could help us define a better a better testing strategy?

Ixchel Ruiz 33:34
Well, you know, Melissa, I mean, sometimes we can have problems, we don’t have too little test, but too many tests, both things are possible and for when you are have too little test, well increase the number it that is easy, I mean, if you increase the things that are your testing over there, you will find errors faster, I mean, that happens. But if you have too many, then you have even more difficult problems to solve, because now you have to think about how to reduce them. Because usually, if we have too many tests, we have as I said constraints, sometimes you can have run every single time every single time that somebody makes a commit or every single time that there is a merge into master which are mean, which shouldn’t be the case, but sometimes the nature of the test are really are either too expensive, require a specific specialized hardware or something like that. So they are really sometimes critical risk restrictions. So what you need to understand or everybody should understand the criteria that dictates or are attached to our test either because of how difficult is To run the test, how much actually helps into verify the quality and behavior of our sport. And so the first thing that I can suggest any single developer on any team is created is criterias. Create this matrix, what is important for us how to understand what is not only important but necessary and what is going to bring the most biennials going to be the most meaningful inside our project. And from there, you will start choosing the different strategies of your test, for example, you can decide, well, we will have this particular critical set of test run once per week. But if we have this kind of changes in the code in this subsection of the parts, we will create or we have to run this particular set of tools. If we’re changing the encryption, then we have to verify this. So as you as you see, there must be classification. Obviously, trying to limit as much the number of tests that you are earning. But keeping in mind, what is mine and mine are meaningful and valuable. But that’s only going to be answered by own matrix of critical points, and how they affect your software.

Melissa McKay 36:37
That totally makes sense. I mean, our tests need just as much care and feeding as the rest of our code base, right? We can’t be sloppy with it, for sure you’ve made some really good points. Well, you called out a couple tools that if you’re not using them, you should be testing cleaners for sure. I definitely remember being in situation where we were using an in memory database for everything just because it was faster. But what you just described, like, there could be a suite of tests that would make sense with an in memory database, but there are times when semantics matters. And you need to know you need to really be using the exact database that you’re using in production. So test containers would have solved that issue for me years ago. That’s something I recommend too, for sure. Alright, well,

Ixchel Ruiz 37:26
the point I was just going to add something is not longer that expensive. So we don’t need to use in memory databases anymore. Because they’re fast, they’re easy to start, they are easy to test. So then the beauty of this containers you don’t longer need to pay that expensive price in terms of how much it’s it takes to start test.

Melissa McKay 37:53
That makes sense and good to now you’re right things are improving all of the time.