DevConf.CZ 2020

Testing linux kernel code is challenging because of the speed and the diversity of the changes. Many companies are
attempting to tackle this through the use of automation and CI (continuous integration).

Red Hat contributes to stabilizing the upstream linux kernel using its Enterprise class hardware.
The Continuous Kernel Integration ("cookie") team has had successes in various ways; e.g. in being able
to scale, adding multiple kernel trees to testing and uncovering kernel bugs.

Over time, more people are starting to view CI for kernel in a bit more positive light.
More cooperation with various companies and individuals could help to make a real difference.

This talk will discuss what Red Hat has done in this space, how it is trying to cooperate with others
and what issues we're seeing in trying to take our work into the next level.

We encourage you to share and invite people who might be interested; this talk
is suitable for anyone in kernel testing/tools, CI and related topics.

In this talk, the attendees will learn how to get started with API testing. Considering the testing pyramid, it is important to have more API tests than UI tests. I will be covering topics including the basics of REST API, why do we need API tests, getting started with API tests, the testing frameworks and libraries to use(pytest, lemoncheesecake, unittest, requests, etc.) and test reporting.

Outline:
- Brief introduction to REST API
- Getting started with API testing
- Which testing frameworks and libraries to use in Python.
- Making API requests, Assertions and Response JSON parsing.
- Using framework: lemoncheesecake to write your API tests
- Understanding the Matchers provided by the framework to assert the API responses
- Live demo(running the API test suite that we created using lemoncheesecake)
- Generating test reports and logging assertions
Slides available at -> https://anarang.github.io/api101s_devconf2020/#slide=1

StackOversight is a novel approach to address the ever-growing concern of copied code within applications. Instead of the traditional route of searching for intra-application code-clones, StackOversight finds code that is copied from online sources, like StackOverflow. Code that is found online is oftentimes unverified and riddled with code-smells and bugs. Utilizing online code too much can lower the quality of code overall and create a nightmare for quality assurance. This session will cover the basics of code-clones and the ways of detecting them so no background knowledge is needed by attendees. StackOversight is a working open-source prototype with initial tests proving successful, as over 500 high-severity clones were found in the Spring Framework enterprise application. StackOversight was developed during a summer internship program as a combined effort of NSF IRES researchers from Baylor University and interns from Red Hat in Brno.

Packit (https://packit.dev) is working on making the packaging of your Fedora and RHEL packages automated from upstream git. Testing Farm (https://packit.dev/testing-farm) is Packit's main testing system. Let's look how to integrate FMF (https://pagure.io/fedora-ci/metadata) based tests with your upstream project. The presentation will include a demo showing a pull request of a GitHub project which will be automatically built for Centos Stream and all Fedora releases, tested on VMs from a community provided cloud, and the results of the testing linked directly to the Github PR. We will also show how you can use the same tests for testing and gating in Fedora and RHEL.

How can we decide if a software artifact can pass certain
gating points in a software delivery pipeline? We need to make sure
that all tests are satisfied, but doing it manually might introduce
days of delays, which is not ideal today. Greenwave, WaiverDB and
ResultsDB are the key elements in Fedora and Red Hat to automate the
gating process. We're going to show you what they are, how they work,
and why they are fundamental for an automated and efficient release
pipeline.

Fuzzing or fuzz testing is an automated software testing technique that involves providing semi-random data as input to test programs. Fuzzing helps with security, stability and performance.
Integrating fuzz testing into the development workflow and CI is a great addition to code quality but also involves new challenges due the special nature of fuzzing.
We will share our experience of running continuous fuzzing for both open-source and close-source C/C++/Golang and Rust projects (systemd between theme). We will discuss challenges, possible solutions and other best-practices in continuous fuzzing.

Agenda
* What is fuzzing? (quick)
* libFuzzer introduction + demo.
* What is continuous fuzzing?
* Current state of continuous fuzzing.
* Challenges of continuous fuzzing.
* What fuzzing is not?
* Current State of C/C++ OSS projects.
* Case studies

cmocka is an elegant unit testing framework for C with support for mock objects. The talk will dive into the features of cmocka with a special focus on mocking. Mocking is a technique to have a test instruct an object how to behave. It allows to do unit testing of functions which you were not able to do before.

In today's competitive environment, performance is the key to the success of a product. While making choices from a set of similar products one of the key considerations is performance. The success story of containers technology can also be attributed to the fact that its performance is better compared to virtual machine.
In this session you will know the different tools that can be used for performance benchmarking.
You will be able to analyse bottlenecks using tools like tcpdump, perf, sar. You will know how to categorize different types of performance bugs. You will know what are the quick tricks to fix some kinds of performance bugs.

Sure you CAN host a database on Openshift/Kubernetes, but SHOULD you? What kind of performance do you see on various storage configurations? Is it fast, is it slow, or is it something in between?

For the last year, both speakers have been testing PostgreSQL and other databases running in Openshift and Kubernetes clusters in order to see what overhead, throughput and response times are like. They've tested in the cloud and on bare metal, with various benchmarks and storage types including local volumes, cloud storage, and the Rook/Ceph Operator. Find out their findings on where cloud native database hosting shines -- and where it doesn't.

Attendees will learn how to evaluate when Openshift or Kubernetes are an appropriate location for their databases, as well as testing methods and configuration tips for best performance.

With the upcoming release of Selenium 4, the Selenium project is moving from a JSON Wire protocol to a W3C protocol for selenium- browser communication and eventually all browser vendors will stop supporting the old protocol for their latest browsers. Therefore if your application’s browser policy states a support to latest versions of modern browsers then you will **have** to migrate your existing tests to Selenium 4 (W3C) when it comes out officially in few months.
This project is right now in Alpha 4 stage and available for testing via a maven repo. In this talk we will walk you through what to expect from Selenium 4 and how to be prepared for this migration.
We will also show code snippets and examples with alpha 4 and its new features like ‘relative locators’ .
The point which we are trying to make through this talk is that unlike the earlier Selenium releases Selenium 4 has a major architectural change and migrating legacy selenium tests is not going to be optional .

Do you rerun your performance tests multiple times because of run-to-run variation?
Are cpu jitter spikes causing your low-latency application to miss important network packets?

Tuning your system for low latency used to be tedious and often error prone. Fortunately the cpu-partitioning tuned profile simplifies that considerably.
And learn how eBPF can help you find where your cpu latencies are coming from.

Come learn what the cpu-partitioning profile is about, how it helps to deliver repeatable performance test results, and see an example where it helped to deliver impressive low-latency results.

This talk is about easy testing the code that needs remote services.

We will show you the approach that helps in situations where you are not able/don’t want to store secrets like auth tokens in CI’s as well as when the communication takes a lot of time. No mocking, no complicated tests.

We will present Requre, our implementation in Python, that helps us to test our projects, that works with services like Github, Gitlab, Pagure, Koji, Copr or git library.

Do you want to know more?
- How to record your session and then replay it to your test code?
- Why is this approach better than mocking?
- How to write simple tests?