Search icon
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
How to Test a Time Machine

You're reading from  How to Test a Time Machine

Product type Book
Published in Mar 2023
Publisher Packt
ISBN-13 9781801817028
Pages 384 pages
Edition 1st Edition
Languages
Author (1):
Noemí Ferrera Noemí Ferrera
Profile icon Noemí Ferrera

Table of Contents (19) Chapters

Preface 1. Part 1 Getting Started – Understanding Where You Are and Where You Want to Go
2. Chapter 1: Introduction – Finding Your QA Level 3. Chapter 2: The Secret Passages of the Test Pyramid – The Base of the Pyramid 4. Chapter 3: The Secret Passages of the Test Pyramid – the Middle of the Pyramid 5. Chapter 4: The Secret Passages of the Test Pyramid – the Top of the Pyramid 6. Part 2 Changing the Status – Tips for Better Quality
7. Chapter 5: Testing Automation Patterns 8. Chapter 6: Continuous Testing – CI/CD and Other DevOps Concepts You Should Know 9. Chapter 7: Mathematics and Algorithms in Testing 10. Part 3 Going to the Next Level – New Technologies and Inspiring Stories
11. Chapter 8: Artificial Intelligence is the New Intelligence 12. Chapter 9: Having Your Head up in the Clouds 13. Chapter 10: Traveling Across Realities 14. Chapter 11: How to Test a Time Machine (and Other Hard-to-Test Applications) 15. Chapter 12: Taking Your Testing to the Next Level 16. Index 17. Other Books You May Enjoy Appendix – Self-Assessment

Continuous Testing – CI/CD and Other DevOps Concepts You Should Know

In the last chapter, we explored different ways of designing user interface (UI) test automation frameworks. This is found at the top of the pyramid that was introduced in the previous three chapters. The topic of this chapter might seem as though it lands at the bottom of that pyramid, so people working in testing tend to forget about it. However, it is crucial for any system to have the right number of tests that confirm the quality of the code changes that are being implemented and delivered to the user. Continuous testing (CT) forces the different tests of the pyramid to be run automatically and continuously across all of the deployment phases of the application.

Deciding the approach for this chapter was a tricky task. On the one hand, many concepts could benefit from exact examples. On the other hand, each of the concepts could be written in a different way depending on the tools used. Our advice is...

Technical requirements

Some degree of programming skills is recommended to get the best out of this chapter, especially for the A basic CT example section. However, it is important that everyone in a company understands the concepts in this chapter.

Therefore, quality experts (SDETs/QA) should be interested in this chapter, as well as developers and DevOps team members. Other roles in the company could also benefit from understanding the concepts in this chapter.

This chapter uses partial examples written in pseudocode, as full code would depend on the tools and platforms used for CI. At the end of the chapter, we will see how to automate a .yml file using Python. Feel free to try this example with your favorite programming language

The code related to these examples can be found in this book’s GitHub repository: https://github.com/PacktPublishing/How-to-Test-a-Time-Machine/tree/main/Chapter06

What is continuous testing?

In order to understand CT and how to achieve it, we must first define CI/CD and other core concepts.

Continuous integration

When several people are working on the same piece of code, issues between the different versions of the code can easily appear. We need a system to keep all the code versions together. The place where code is kept is called a code repository.

CI consists of frequently integrating and merging feature code into a shared repository, preferably several times a day. Each integration can then be verified by an automated build and automated tests, which will be part of CT. This is done from within the repository or the different environments set up in the deployment pipeline. The goal is to ensure there are no integration issues and to identify any problems early.

As we evaluate the state of the code after each integration, we can locate and fix integration problems individually. If we do not use this technique, it is harder to...

CI/CD and other DevOps concepts that you should know

In this section, we will cover some DevOps concepts you should be aware of and understand in order to be fully involved with and committed to CI/CD systems. Feel free to skip the blocks you are already familiar with.

Pipelines

A pipeline (also known as a deployment pipeline) is the way we organize our deployment system. Each of the steps in our pipeline is matched with an environment that we use to configure the system under development, merge the different versions, and test them.

Branches

When developing an application, it is convenient to keep different versions of the code, especially when such code is built by different developers at the same time. Each version could correspond with a feature or with a state of the application. The reason that these are called branches is from the analogy of a tree, where the main trunk can split into different branches.

A typical design of branches can look as shown in Figure...

Types of continuous tests

From Chapter 2, The Secret Passages of the Test Pyramid – The Base of the Pyramid, to Chapter 4, The Secret Passages of the Test Pyramid – The Top of the Pyramid, we explored different types of testing in the test pyramid. In this section, we will see how and where these (and other tests) should be handled through the different steps of our pipeline system, continuously executing them to ensure the high quality of our deployment system.

Unit tests/code review testing

Continuing the example of Figure 6.1, we can commit a feature branch at any time. When we are happy with the contents of the feature branch, ideally after some testing (such as unit tests and code reviews) has taken place, we can merge it to the next branch, including the main trunk.

The test expert should configure the coverage and verify it. We can also create tools to check and ensure the quality of the code being committed before undergoing a code merge.

For more...

Tools for CI/CD

In this section, we will mention some of the tools I have seen during my career, with no preference for any of them specifically. We are sure (in fact, we hope) that you are able to find alternatives and consider the best ones for you. These are just examples, and we are sure there are many other interesting ones.

We have divided the various tools into sections, but nowadays most tools allow for several uses.

Programming languages

Most of the CI/CD tools would use some programming language to specify the instruction of what the deployments need to do at every step, such as running tests, installing commands, and so on. Each favors one programming language over another, but in my mind, there are some that you should be familiar with. In the following table, we provide a summary of interesting languages to get familiar with. The new concepts or words in the table will be reviewed in the following sections.

A basic CT example

In this section, we are going to investigate how it is possible to automate CT from zero, without any tools (other than Git for source control). For simplification, we will not cover CI, but we challenge you to try it yourself as a learning project. Feel free to review the definitions of CI/CD at the beginning of this chapter again if you struggle to understand what would be different.

In our examples, we will be using vstest to create and execute tests, as this can be easily called from batch/cmd and from other programs. This tool generates output that we can add to a text file for later analysis. Then, we will showcase how to create a YAML file to run the entire process to get you familiar with YAML and how it links all the tools together. Finally, we will use Python to call and execute the YAML file. This way, you can see how different tools with different programming languages can interact.

I hope that the concepts explained in this section help you improve...

Summary

In this chapter, we covered CT and other different DevOps concepts that we should be familiar with to ensure quality across the entire development and deployment, and thus proving how CD really is all about automation. We will learn a bit more about how everything interconnects, including some diagrams, in Chapter 11, How to Test a Time Machine (and Other Hard-to-Test Applications), in the Architecting a system section.

In the next chapter, we will look at something challenging but nonetheless needed to understand the rest of the chapters fully, the mere mention of which might initially intimidate some of you when reading it, but trust me, we will make it as fun as possible. It is also recommended that you read it before the next chapters as it will lay out important concepts that you may need for them. If you need to, take a deep breath, and then keep on reading…

Further reading

lock icon The rest of the chapter is locked
You have been reading a chapter from
How to Test a Time Machine
Published in: Mar 2023 Publisher: Packt ISBN-13: 9781801817028
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime}
...