I haven’t done any testing so far other than manual testing, deploying everything and seeing if it works. A lot of developers are firm believers in unit testing, but I’ve taken another approach. In the world of microservices, where the services themselves are rather simple but the coordination among the services is complex, I think the best way to test is running tests against services that are running in the system. In our case, there’s only one service so far, but what happens when we break down the services into a lot of little services? The complexity that was inherent inside the monolithic application is now distributed across services. It’s that complexity that is the cause of most of our issues, so we must conquer it by testing out the system as a whole.

If I was building a library, or a framework, I would still be doing unit testing. But most of my time is spent building microservices, and there just isn’t enough in them to justify unit tests. So I wait until they’re deployed and then I can create a suite of tests that run against the real system. For my money, it’s a lot better use of time and it finds the real issues much faster. Back in the day, when deploying software was difficult, unit tests made sense because they caught a lot of issues before the effort was made to deploy. Now deployment can be automated, so we shift our focus to testing after deployment.

I just spent a couple of paragraphs justifying what might be a contentious issue with other developers. Now let’s get down to testing.

But first, let me mention that while the title of this article is Build Automation for Beginners, that doesn’t mean it’s easy. We’re using very sophisticated tools here, and a lot of them are cutting edge, which means there may be problems getting them to work in all but the most common cases. By ‘absolute beginner’ I mean that you started off with just a plain laptop and a strong desire to learn.

There’s not a lot of programming here, it’s mostly what people in other industries call post-production. But in order for you to have the skills you need to be a generalist, in order for you to get that plum job in a start-up where you’ll be required to wear all hats, It’s required learning. So if you’re fearless, read on!

This article assumes you have read the others in the series, and have things installed on your laptop, including Docker Desktop, Git, and Atom. You can use another editor than Atom, but I find it is a good general-purpose tool for editing files of all types. We will be extending the build pipeline we created in the last article, specifically for testing the application build built throughout this series.

This application we’re testing is a little different than what I normally build where the services just return data. This application takes the data and builds up the HTML that the browser displays. I could write an entire article on testing this application, but I’m going to keep things simple for now and just make a few assertions. I’m going to take the output and make sure it parses as proper HTML, and I’m going to assert that the first line includes the phrase “My Awesome Server.”

Since this test will be run under Kubernetes, I’m going to create an image that contains the test. To keep the test files from not getting mixed up with the application files, but still stay in the same repository, the first thing I will do is create a test folder. Back in Atom, right-click on myfirstrepository, select ‘New Folder’, and type in ‘test’. All of our test code will go in there. To make sure the test code isn’t added to our application code, open up the .dockerignore file and add a line with just ‘test’. This will keep anything in the test folder from being added to the application image.

I should mention that my usual strategy for creating repositories, is one repository for every artifact. So for every image that I build, normally I would have everything needed to build that artifact in a single repository and nothing else. This ensures that we are sharing code through binary repositories that allow strict versioning. I always say “Sharing is hard, but not sharing is harder.” If you start your projects off with sharing in mind, they will grow much less effortlessly then if you decide after your project grows too unwieldy to manage and you decide to split things up after the fact. And with binary repositories like Artifactory or Nexus, you have no excuse not to share through proper channels.

#jenkins #jenkins-pipeline #kaniko #docker #kubernetes