Testing approaches and Cloud-native microservices
Do you know how Amazon started? As an online bookstore, right? Well, No You may be unaware though, that Jeff Bezos started out by buying books from distributors and shipping them to customers every time his online store received an order. The high book sales meant it made sense to keep adding more products to the store, then he acquired warehouses, and finally provided each user with a personalized experience on the website.
One of the biggest reasons why startups fail is because they design their initial product based on assumptions. Entrepreneurs fall into the trap of assuming that their product will solve a problem better than any existing solution on the market. They also assume that people care enough about the problem to pay for a solution. When these assumptions go wrong, the startup never gets off the ground. Also when launching an initial product in the open market. There are always risks involved in the product for investors. Here comes the Minimum Viable Product and for applying these iterative changes quickly, it becomes more and more important for a designer and developer to be familiar with the Test and Behavior-Driven Development and The impact and importance of cloud-native microservices on application design.
This is the third article in the “DevOps” series. If you have skipped the previous ones, I would request you to check them out as well.
Minimum Viable Product
In this part of the story, we’ll define a minimum viable product (MVP) and recognize how an MVP should be used to give the customer what they really want.
Let’s first understand what it is not because there are some misconceptions that a minimum viable product is the same as phase one of the product, or the first beta, or something like that. This is not what a minimum viable product is.
A minimum viable product is a minimal thing that you can do to test a value hypothesis and gain learning and understanding. You might say it is the cheapest thing you can do to prove a hypothesis.
You can finish the first MVP, then get the results and move to the second one, and so on. The difference between these two is that the first one is all about delivery. What am I going to deliver? But the second one is all about learning. What can I learn? What can I learn from putting out this MVP and getting feedback and then maybe making the next one even better? I always try to put the Wikipedia definition as well, so you have a clear picture. Let’s have a look into that as well
A minimum viable product is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. — Wikipedia
Let’s look at the famous example of the Car. There’s a team that’s developing a minimum viable product for a customer that wants a blue car. And so, in the first iteration, they deliver a wheel. The customer’s like, “What am I going to do with a wheel? I can’t do anything with this.” Well, we’re working iterations, they say, we’re trying to be agile here. In the next iteration, we’ll give you something more. And they give the customer a chassis. And the customer responds, “I still can’t do anything with this chassis.” And then, they give them a car with no steering wheel and then eventually they get the whole car. Now the customer gets this coupe. There was no feedback along the way. The team didn’t know until the end whether the customer was going to like what they built or not. The team did not understand how to create a minimum viable product. They were just doing iterative development with no regard to whether each increment was useful or not.
The second team understands the value of creating an MVP. At first, they give the customer a skateboard and the customer says, “What’s this? I asked you for a car and you’re giving me a skateboard.” The team explains we’re testing the color. How do you like that color blue? Is that the color you want? The customer says, “Oh yeah, blue’s kinda cool but you know it’s really hard to steer.” The team says, “No worries.” In the next MVP, they give him a way to steer it. The customer says, “Well, okay, you did give me a way to steer it but I can’t go very fast. I need a better form of locomotion.” The team deals with that in the next MVP. In the next iteration, they give them pedals to go faster. Somewhere along the way, while riding on that motorcycle feeling the wind in their hair the customer decides, “I really want a convertible!”
In the first instance, the customer got exactly what they asked for months prior because the development team was just following a plan. But in the second instance, the customer got exactly what they desired because they were working iteratively and interactively with the development team.
In the end, you develop something that’s a little bit different but it’s closer to what the customer really wants. Giving the customer what they really want is the main purpose of delivering an MVP. A minimal viable product is a tool for learning. It is an experiment to explore the value proposition with your customer. This experiment may fail and that’s okay because failure leads to understanding. What did you learn from that failure? What did it teach you? What is the next experiment? What will you do differently next time? These are the questions that lead to gaining knowledge and understanding about what you are building. This is why we use MVPs in DevOps.
Test-Driven Development (TDD)
We’ll now see the Test-Driven Development (TDD), how TDD produces higher-quality code, define the Red, Green, Refactor workflow, and see the importance of TDD for DevOps.
Test-Driven Development (TDD) means that your test case drives the design and development of your code. You don’t write code and then test it. You write the test cases first. You write the tests for the code you wish you had, then you write the code to make them pass. That may sound counterintuitive. How can I write test cases for code I haven’t written yet? How can you write a design for code you haven’t written yet? You describe in the design how the code should behave and then you write the code that behaves that way. TDD has no difference. This keeps you focused on the purpose of the code, that is, what’s it supposed to do.
TDD will keep you writing solid code. So what is the TDD workflow? You write a failing test case (right?) for the code you wish you had. Then write just enough code to make it pass. It doesn’t have to be perfect. It doesn’t have to be pretty. It does have to make the test pass. Then you refactor the code to make it better and increase the quality. Finally, repeat the process. This is known as Red, Green, Refactor. Many of the testing tools follow this scheme. These tools output failing test cases in red and passing test cases in green. This is how Red, Green, Refactor got its name.
Why is TDD important to DevOps?
- First and foremost, it saves time when developing. As you add new features to the code or changes to existing features, the test cases will quickly let you know if something broke.
- It allows you to code faster because you are more confident. You don’t have to worry if a change you just made broke something. When you refactor code, you can move much faster because you know the test cases will catch any changes in behavior.
- TDD ensures that the code is working as you expected. If you write the test cases first to define the behavior you want, you will know that you have achieved that behavior when the tests pass.
- TDD also ensures that future changes don’t break the code. Failing test cases will instantly alert you that someone has introduced something that broke the code.
- Finally, and most importantly, in order to create a DevOps pipeline (a CI/CD pipeline), all tests must be automated unless you want to push bugs to production faster. A lot of companies don’t understand this. They want to automate using Continuous Integration (CI) and Continuous Delivery (CD), without automating their test. Unfortunately, you can’t have a CI/CD pipeline without automating your tests.
Behavior-Driven Development (BDD)
Let’s now look at Behavior Driven Development (BDD), How BDD can drive customer expectations, and describe the key benefits of BDD.
Behavior-driven development (BDD), as its name implies, focuses on the behavior of the system as observed from the outside in. This is different from test-driven development, which focuses on the minutiae of how the system works inside.
BDD is great for integration testing to see if all of the components are behaving together. It forces you to think “from the outside in.” In other words, you implement only those behaviors that contribute most directly to business outcomes. One of the advantages of BDD is that it describes behaviors in a single notation, which is directly accessible to domain experts, testers, developers, and customers. This improves communications across the team.
If we compare BDD to TDD we see that they are coming from opposite directions. BDD describes the behavior of the system from the outside in. It is looking at the system as a consumer of it would. While TDD tests the functions of the system from the inside out. It is making sure that each component is working correctly while BDD is making sure that they all work together at a higher level. Putting another way…
BDD ensures that you are building the right thing. ‘Do you have the right set of capabilities and these behaviors?’. TDD ensures that you are building the things right. ‘Does each feature perform the task that it was intended to?’
The workflow starts with the developers, testers, and customers exploring the problem’s domain and collaborating to produce concrete examples that describe the behavior they want.
BDD improves communication among the team members like developers, testers, product owners, and other stakeholders. It leads to more precise guidance on how the system should behave. It does this by providing a common syntax that is close to everyday language and has a shallower learning curve compared to TDD tools. Tools targeting the BDD approach generally afford the automatic generation of technical and end-user documentation from the BDD feature specification. Having clear behavior visibility results in higher-quality code, which reduces the cost of maintenance and eliminates the risk. Finally, with BDD acceptance criteria you are already converted to user stories and test scenarios before the actual development. Thus, automating test cases can start creating test processes even before the product is tested.
Cloud-Native Microservices
We’ll now recognize the impact of cloud-native microservices on application design, describe stateless microservices, and compare monolithic and microservices architectures.
To fully leverage DevOps, you need to think differently about application design. You need to be thinking about cloud-native microservices.
This image shows an application that is designed as a collection of small microservices. Each one of these services is independent of the others. Each service is a particular domain of the application. You may have gathered from the names of the services that this example is a ride-sharing service. There are drivers, payments, trip management, and notifications. These are all small services that are single-purpose based around a business domain. Notice the lines going from one service to the other. These are pointing to the REST APIs (Representational state transfer architectural style Application Programming Interface). No service is accessing another service’s database. In fact, databases aren’t even included in the picture.
This is a cloud-native design using microservices. It is a collection of stateless services. Cloud-native means, “born on the cloud,” taking advantage of the horizontal scalability that the cloud has to offer. These services are following the guidelines set forth in “The Twelve-Factor App,” which describes how cloud-native applications should behave. This was first created in 2011 by the Heroku team. Heroku was one of the first platform-as-a-service implementations that paved the way for the cloud-native platforms that we have today. Applications are designed as a collection of stateless microservices. Stateless doesn’t mean that the application doesn’t have a state. It means that the services don’t maintain the state or any hidden state.
The state is persisted in a database and each service maintains its own state in a separate database or persistent object-store. Separation of the state is important. If services were to share state you wouldn’t have microservices. You would just have a distributed monolith. Resilience and horizontal scaling are achieved through deploying multiple instances. Once you break your application down into multiple independent services you can scale them independently as needed.
Final Thoughts
MVP is not the phase-one or the first beta of a product. It is the cheapest thing you can do to prove a hypothesis. Minimum viable product is as much about delivery as it is about building what the customer really desires. Test-driven development is writing the test for the code you wish you had, then writing the code to make the test pass that allows you to develop faster and with more confidence while Behavior-driven development focuses on the behavior of the system from the outside in. It looks at the system as a consumer of it and we also talked about Microservices are built around business capabilities and are independently deployable by fully automated deployment machinery and its architecture enables independently deployable microservices that take advantage of horizontal scaling and result in more resilient services.
That’s all for now!
In the next article, we’ll look into the Impact and Important to embrace failure and designing for it. If you enjoyed this article please do Like and Follow. Do let me know if I have skipped anything and what your thoughts and comments are on this.
