In this video, learn how to move from manual testing to automated with test-driven development (TDD) and behavior-driven development BDD).
- So far we've covered continuous integration and continuous delivery, but by now you're probably wondering what's the catch? I mean, it all sounds good. Faster deploys, less work in progress. Is it just too good to be true? Well, there really isn't a catch but there's some fundamental shifts you have to make when you're moving to continuous delivery. One area that deserves extra attention is testing. For this section on testing, we're going to cover seven different types of testing that often get implemented in continuous delivery. Let's kick off with unit testing. These are the tests done at the lowest level of the language or framework that it supports. Let's say you have a calculator application. A function called add would take two numbers and big surprise here, it adds them together. In unit testing, we would write a test inside the code base to validate that function. These are the hallmarks of unit testing. Usually the fastest testing available. It stubs out external dependencies with fake values and it easily runs on the developer's machine. Next up is code hygiene. Code hygiene is the sum of the best practices from your development community for the particular language or framework that you're using. It is usually accomplished through linters, formatters, and you can also check for band functions in your code. Next is integration testing. It's technical testing similar to unit testing, but performed with all the apps components and dependencies operating in a test environment. Next we're lumping together a few. Test driven development, behavior driven development and acceptance test driven development. Now, they're all related movements in software development that focused on testing from an outside in perspective. Each one varies slightly in their implementation. So even though we're lumping them together in the same category of tests, let's briefly cover what they mean. TDD, test driven development. It's a development practice that starts with writing tests before you write any code. The flow with TDD is that you start with the desired outcome written as a test. You then write code to pass the test and then you rinse, wash and repeat. Now this flow encourages high feedback. And a bonus is that while the application is being written, a comprehensive test suite is also being developed. Behavior driven development, also called BDD. That encourages the developer to work with a business stakeholder to describe the desired business functionality of the application and expresses the test in a DSL that is pretty close to the English language. For example, in our calculator application it might look something like this. Given I have a calculator, when I give it two numbers to add then it should return the sum. Next we have acceptance test driven development, ATDD. It builds on TDD and BDD and it's involved defining scenarios from the end user's perspective. You write automated tests with examples of these use cases and then running them repeatedly while the code is being developed. Okay, so all the tests that we've talked about so far has been reasonably fast, but sometimes you're going to encounter slower tests and slow tests, they can't be ignored because there's not really a magical way to speed them up. If we start adding a bunch of slow tests to the pipeline then we start violating the five minute coffee rule. Well, to get around this, there are three strategies I like to use. First, use non-blocking tests in your pipeline. Second, use time scheduled testing, like doing a nightly test suite. Third, use monitoring to accomplish some of your testing goals. Okay, let's move to the next one. Infrastructure testing. This is the next test category and sometimes it can be a slow running test. It involves starting up a host and running the configuration management code, running all the tasks and then turning it all off. Another test category is performance testing. Basic performance testing should be part of everything that you do, but there's also a dedicated performance test that you want to have. You want to have load tests, stress tests, soak tests, and spike tests. All these tests are really great for out-of-band nightly runs, they're usually long running and they consume a lot of resources. The last category is security testing. It might be useful to think about this as a simulated attack test. I'm a developer on the open source tool called the Gauntlet. Gauntlet let's you use BDD language when testing for security attacks from the outside in. All right, well that wraps up the list of QA and how all this stuff fits in together. Testing is critical to get right if you want to be able to set up a continuous delivery pipeline. It's the only way you can trust that the changes you made won't break the system and keep up a high rate of speed.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps