# Test coverage Test coverage is a software-testing metric measuring how much code in a repository is exercised by tests. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Cypress Cloud MCP adds test details, filters, and compact responses DevFeed: [Cypress Cloud MCP adds test details, filters, and compact responses]() Original publisher: [Read original article]() Published: 2026-09-15T16:21:48Z Content type: release Language: en Sources: [Cypress Blog]() Topics: [Cypress](), [MCP](), [Test coverage]() Tags: [cypress](), [mcp](), [release](), [responses](), [september-2026]() ### AI overview Cypress Cloud MCP now provides compact responses by default, new per-spec and per-test tools, filters by run, spec, and test status, and duration data across multiple levels. It also adds deeper links for accessibility and UI coverage reports. ### Source excerpt New tools, more data, smaller responses: what's new in Cypress Cloud MCP as of September 2026. ## Improving Test Coverage in the Interview Coach Application with GitHub Copilot DevFeed: [Improving Test Coverage in the Interview Coach Application with GitHub Copilot]() Original publisher: [Read original article]() Author: Aaron Powell Published: 2026-09-15T16:00:21Z Content type: tutorial Language: en Sources: [Visual Studio Blog]() Topics: [test-coverage](), [Test coverage](), [GitHub Copilot](), [App](), [Visual Studio](), [Code]() Tags: [agent](), [analysis](), [code-coverage](), [copilot](), [github-copilot](), [productivity](), [projects](), [run](), [test](), [test-coverage](), [testing](), [tests](), [unit-tests](), [visual-studio]() ### AI overview This tutorial explains how to improve test coverage in the Interview Coach application by establishing a baseline, using GitHub Copilot's Test Agent to generate unit tests, and analyzing coverage across the solution. The article reports coverage increasing from 37% to 81%. ### Source excerpt Today I want to look at how we can improve on the test coverage that we have in the Interview Coach application. This application has some unit tests in it already, but I'm sure there is room for improvement. Defining our baseline Before we start writing tests, it's a good idea to have a baseline [...] The post Today I will... improve test coverage appeared first on Visual Studio Blog. ## Making testing work better for AI driven development DevFeed: [Making testing work better for AI driven development]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-09-10T09:28:14Z Content type: release Language: en Sources: [Semaphore Engineering]() Topics: [Testing](), [Development](), [Artificial Intelligence](), [Test coverage](), [RSpec]() Tags: [ai](), [flaky](), [framework](), [product-news](), [test-coverage](), [testing](), [xunit]() ### AI overview Semaphore describes product work to make testing more useful for developers and AI agents. The update covers richer test reports from testing frameworks, signal-based flaky-test detection, and code-graph-based selection of tests affected by code changes. ### Source excerpt AI agents can generate and modify code quickly. But when a test fails, speed is no longer enough. The agent needs enough context to understand what happened, why it happened, and whether the code or the test itself needs to change. In our latest product update, Marko Gaćeša is joined by Semaphore engineers Nick and [...] The post Making testing work better for AI driven development appeared first on Semaphore. ## ESP-BIST in Action: A Self-Testing HMI using ESP32-P4 DevFeed: [ESP-BIST in Action: A Self-Testing HMI using ESP32-P4]() Original publisher: [Read original article]() Author: John Lee Published: 2026-08-22T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32-P4](), [Testing](), [Test coverage](), [Espressif](), [Microcontroller](), [RISC-V](), [boot]() Tags: [blog](), [display](), [esp32-p4](), [espressif](), [hmi](), [lvgl](), [modbus](), [risc-v](), [safety](), [startup](), [test-coverage](), [testing]() ### AI overview This tutorial explains how ESP-BIST provides IEC 60730 Class B self-test coverage on Espressif SoCs. It demonstrates an ESP32-P4-powered HMI using an M5Stack Tab5, Modbus communication with a simulated motor controller, and an LVGL touchscreen. The article describes post-boot and runtime tests, safe-state handling, and Host Diagnostics using the low-power RISC-V core. ### Source excerpt ESP-BIST brings IEC 60730 Class B self-test coverage to Espressif SoCs, and this article walks through what that actually means before putting it to work. Using an ESP32-P4-based M5Stack Tab5 as a Modbus HMI for a simulated motor controller, we show how a SoC that can prove its own health is a chip you can trust to draw a "safe" screen without lying about it. ## Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings DevFeed: [Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings]() Original publisher: [Read original article]() Published: 2026-08-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Rails](), [upgrade](), [version](), [Test coverage](), [RSpec](), [Docker Compose](), [Ruby]() Tags: [coverage](), [docker-compose](), [rails](), [rspec](), [ruby](), [upgrade](), [version]() ### AI overview An account of upgrading a multi-tenant JSON API from Rails 4.2.7.1 to Rails 8. The author argues that estimates focused on version gates missed the actual risks, and describes how characterization tests, an extracted frontend, and containerized development reduced the work. ### Source excerpt . [Upgrading Rails 4... ## Rust-proof your code with our new Testing Handbook chapter DevFeed: [Rust-proof your code with our new Testing Handbook chapter]() Original publisher: [Read original article]() Author: "Paweł Płatek" Published: 2026-07-13T11:00:00Z Content type: tutorial Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Rust](), [Security](), [mutation-testing](), [Tooling](), [Test coverage](), [Memory Safety](), [Rust formal verification](), [Concurrency](), [Claude Code](), [Claude]() Tags: [application-security](), [claude-code](), [concurrency](), [measurement](), [memory-safety](), [mutation-testing](), [rust](), [security](), [testing](), [testing-handbook](), [tooling]() ### AI overview A new Testing Handbook chapter presents techniques for security testing Rust programs and systems. It covers Rust security limitations, dynamic and static analysis, undefined-behavior detection with Miri, property testing, coverage and mutation testing, Clippy, manual code review, memory zeroization, model checking with Kani, and dependency supply-chain vetting. The article also announces rust-review, a Claude Code plugin for automated Rust security reviews. ### Source excerpt We've added a new chapter to our Testing Handbook: a comprehensive guide to security testing Rust programs. This chapter covers the tools and techniques we use at Trail of Bits to validate the security of Rust programs and systems. fn main() {(|f:&dyn Fn(u128)->Box< dyn Iterator+'static>|f(*[&( 0x7B736D70683F73u128<<64| 0x7A6A6D7C3F7A667D),&(0x7B736Du128 <<64|0x70683F7073737A77)][((std::hint:: black_box(0.0f64)/0.0).to_bits()>>63)as usize]) .for_each(|c|print!("{c}")))(Box::leak(Box::new(|n: u128|Box::new(std::iter::successors(Some(n),|&n|Some(n>>8) ).take_while(|&n|n>0).map(|n|((n as u8)^0x1F)as char))as _)))} What's in the chapter The chapter starts with a security overview of what Rust's guarantees do and don't cover, including underappreciated issues like unwind safety, nondeterminism, and arithmetic errors. This leads into an overview of dynamic analysis, which covers a range of boosters for unit tests, how to use Miri to detect undefined behavior, property testing with proptest, coverage measurement, and mutation testing. The static analysis section then covers Clippy in depth, including a list of our favorite lints. Beyond tooling, the chapter also covers what we've learned from auditing Rust codebases directly. Our gotchas and footguns checklist is a great reference for manual code reviews, and will help you find subtle issues like a & b == c having different operator precedence than in C. The memory zeroization section offers three solutions to the tricky problem of guaranteeing that secrets are erased from memory. Finally, the specialized testing sections cover tools like Kani (a model checker), and the supply chain section covers the full toolchain for vetting dependencies. Still oxidizing We've also released rust-review, a Claude Code plugin for automated Rust security reviews. Co-built with Aptos Labs, it targets over a dozen bug classes, from memory safety and concurrency hazards to FFI pitfalls and async cancellation issues. It's a fast wa ## Code Smell 320 - Vanity Coverage DevFeed: [Code Smell 320 - Vanity Coverage]() Original publisher: [Read original article]() Author: Maxi Contieri Published: 2026-06-23T23:32:02Z Content type: tutorial Language: en Sources: [Maximiliano Contieri - Software Design]() Topics: [Testing](), [mutation-testing](), [Test coverage]() Tags: [coverage](), [mutation-testing](), [tests]() ### AI overview The article describes vanity coverage: tests that execute code without verifying meaningful behavior, which can create false confidence and allow defects to reach production. It recommends behavior-focused assertions and mutation testing to identify ineffective tests. ### Source excerpt TL;DR: You write tests that touch every line but verify nothing, creating false confidence in a broken system. Problems 😔 False confidence Hidden production defects Misleading metrics Wasted tes ## Catch visual regressions with Snapshots, now in beta DevFeed: [Catch visual regressions with Snapshots, now in beta]() Original publisher: [Read original article]() Author: Max Topolsky Published: 2026-06-11T09:00:00Z Content type: release Language: en Sources: [Sentry Blog]() Topics: [Testing](), [ci](), [Front end](), [User experience (UX)](), [Test coverage]() Tags: [agent](), [ci](), [frontend](), [sentry](), [testing](), [ux]() ### AI overview Sentry Snapshots is in beta and provides screenshot diffing in CI to detect unintended visual changes on each commit. The article explains snapshot testing, its use as a guardrail for agent-generated changes, and how Sentry used Snapshots to improve its own toolbar UX. ### Source excerpt Sentry Snapshots is now in beta. Get screenshot diffing in CI to catch unintended visual changes on every commit, for any platform with a frontend. ## How we used Quint to find over 10 bugs in SQLite while hardening Turso DevFeed: [How we used Quint to find over 10 bugs in SQLite while hardening Turso]() Original publisher: [Read original article]() Author: Glauber Costa Published: 2026-05-18T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Turso](), [SQLite](), [Formal methods](), [Formal verification](), [API](), [SDKs](), [Test coverage]() Tags: [api](), [article](), [c](), [community](), [engineering](), [formal-methods](), [formal-verification](), [how-to](), [open-source](), [sqlite](), [testing](), [turso]() ### AI overview This article describes how a Turso community member modeled the SQLite C API in Quint, generated execution traces, and ran them against real SQLite to uncover more than 10 bugs. It presents the approach as an effort to strengthen Turso's testing and explore more accessible formal methods. ### Source excerpt A Turso community member modeled the SQLite C API in Quint, ran the generated traces against real SQLite, and uncovered more than 10 bugs along the way. ## Designing synthetic datasets for the real world: Mechanism design and reasoning from first principles DevFeed: [Designing synthetic datasets for the real world: Mechanism design and reasoning from first principles]() Original publisher: [Read original article]() Published: 2026-04-16T14:41:00Z Content type: article Language: en Sources: [The latest research from Google]() Topics: [datasets](), [Synthetic Data Generation](), [synthetic-data](), [Machine learning](), [machine learning research](), [Test coverage](), [Scalability]() Tags: [ai](), [datasets](), [evaluation](), [generation](), [generative-ai](), [machine-intelligence](), [machine-learning](), [machine-learning-research](), [natural-language-processing](), [privacy](), [reasoning](), [research](), [scalability](), [synthetic](), [synthetic-data-generation]() ### AI overview Google Research introduces Simula, a framework that treats synthetic data generation as dataset-level mechanism design. It uses reasoning from first principles to control coverage, diversity, complexity, and quality for scalable generation in data-scarce or privacy-sensitive domains. ### Source excerpt Generative AI ## The Way of TDD DevFeed: [The Way of TDD]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2026-03-10T12:24:00Z Content type: article Language: en Sources: [Google Testing Blog]() Topics: [Test-driven development](), [Test coverage](), [Development](), [Algorithm](), [Code]() Tags: [algorithm](), [article](), [bartosz-papis](), [bugs](), [code](), [development](), [quality](), [refactor](), [tdd](), [test](), [test-coverage](), [tests](), [tott]() ### AI overview This article explains Test-Driven Development as a red-green-refactor cycle: write a failing test, make it pass with minimal production code, and then refactor. It describes reported benefits and limitations, and demonstrates the process by modifying a voting algorithm to support abstentions. ### Source excerpt This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Bartosz Papis Test-Driven Development (TDD) is the practice of working in a structured cycle where writing tests comes before writing production code. The process involves three steps, sometimes called the red-green-refactor cycle: Write a failing test Make the test pass by writing just enough production code Refactor the production code to meet your quality standards Research shows TDD has several benefits: it improves test coverage, reduces the number of bugs, increases confidence, and facilitates code reuse. This practice also helps reduce distractions and keep you in the flow. TDD also has its limitations and is not a silver bullet! See the Wikipedia article about TDD for a detailed explanation and references. Here is a short practical example. Assume you need to modify the following voting algorithm to support the option for voters to abstain: def outcome(ballots): if ballots.count(Vote.FOR) > len(ballots) / 2: return "Approved" return "Rejected" 1. We start by writing a failing test - as expected, the test doesn't even compile: def test_abstain_doesnt_count(self): self.assertEqual(outcome([Vote.FOR, Vote.FOR, Vote.AGAINST, Vote.ABSTAIN]), "Approved") 2. We fix the compilation error by including the missing enum option: class Vote(Enum): FOR = 1 AGAINST = 2 ABSTAIN = 3 Now that the test compiles, we fix the production code to get all tests passing: def outcome(ballots): if ballots.count(Vote.FOR) > (len(ballots) - ballots.count(Vote.ABSTAIN)) / 2: return "Approved" return "Rejected" 3. We now refactor the code to improve clarity, and complete an iteration of the TDD cycle: def outcome(ballots): counts = collections.Counter(ballots) return "Approved" if counts[Vote.FOR] > counts[Vote.AGAINST] else "Rejected" Learn more about TDD in the book Test Driven Development: By Example, by Kent Beck. ## Launching Interop 2026 DevFeed: [Launching Interop 2026]() Original publisher: [Read original article]() Author: Jake Archibald Published: 2026-02-12T17:07:24Z Content type: article Language: en Sources: [Mozilla Hacks - the Web developer blog]() Topics: [Web](), [Web platform](), [web-standards](), [browsers](), [Test coverage](), [dashboards](), [WebRTC](), [view transitions](), [CSS]() Tags: [apple](), [browser](), [css](), [featured-article](), [firefox](), [google](), [interop](), [microsoft](), [mozilla](), [uncategorized](), [view-transitions](), [web](), [web-developers](), [web-platform](), [webrtc]() ### AI overview Mozilla's Interop Project is launching Interop 2026, continuing its cross-browser effort to improve web compatibility through shared priorities and Web Platform Tests. The article reviews Interop 2025's progress, including higher overall scores, broader cross-browser support for major web platform features, and improved reliability for existing features such as WebRTC, CSS Flexbox, and CSS Grid. ### Source excerpt The Interop Project is a cross-browser initiative to improve web compatibility in areas that offer the most benefit to both users and developers. The group, including Apple, Google, Igalia, Microsoft, and Mozilla, takes proposals of features that are well defined in a sufficiently stable web standard, and have good test suite coverage. Then, we come [...] The post Launching Interop 2026 appeared first on Mozilla Hacks - the Web developer blog. ## Using AI Coding Tools to Accelerate Test Coverage DevFeed: [Using AI Coding Tools to Accelerate Test Coverage]() Original publisher: [Read original article]() Published: 2025-11-01T07:00:00Z Content type: opinion Language: en Sources: [Mary Rose Cook]() Topics: [Testing](), [Test coverage](), [codex](), [Claude Code](), [Claude]() Tags: [claude-code](), [codex](), [prompt](), [review](), [test-coverage](), [testing]() ### AI overview A Notion engineer reflects on using Claude Code guidance and Codex to speed up test writing during a time-limited test-coverage sprint. The author describes prompting Codex to prioritize important or complex functions and to carry a task from a function name through creating a pull request. ### Source excerpt At Notion, we've been doing a quality sprint to increase our test coverage. Friday was the last day, and I wanted to get some more tests written. Time was short, which forced me to break my usual workflow. Not that I really have a usual workflow, these days. New AI-augmented programming tools and techniques come out every day. Everything is changing so fast that you can frequently become 10% more productive, forever, with a few minutes or a few hours invested. So, I push myself to try new things. But, inevitably, workflows are sticky. It's hard to change a habit. Extra cognitive load to monitor and refine the technique. Extra willpower to overcome the inertia of the familiar. Extra gumption to risk wasted time on something that isn't helpful. So I have my mega list of stuff to try and every few days I'll pluck something off it to try. But Friday was eye-opening. With time short, I wanted to get as much done as possible. And failure would mean only a few hours lost. We already had a bunch in place to speed things up. A Claude Code skill that my colleague, Jimmy, wrote. It laid out a careful, thorough process for writing tests. It included looking at our testing guide, tips on what to mock and an entreaty to look at surrounding test coverage. I pointed Codex at the Notion doc listing functions that needed coverage. I told it to find functions that are core parts of the system, or that have complex logic. This way, we could prioritize our time towards testing code that was important or gnarly. And, on Friday, here's the new stuff I tried - I'm rushing. Jimmy's skill is written for Claude, but I use Codex. What if I just point Codex at the skill directory in Claude's config? I'm rushing, so I have to get out of the loop. I need a process that can autonomously go from function name to PR. So I wrote a prompt with these steps: read the guidance on writing tests, write tests, create a branch, commit, review the code, refine the code, put up a PR. I'm rushing, so it's going ## How To Refactor Legacy Code DevFeed: [How To Refactor Legacy Code]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-04-12T05:01:26Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [Refactoring](), [Testing](), [Dependency injection](), [Test coverage](), [Mocking]() Tags: [dependency-injection](), [how-to](), [legacy-code](), [refactor](), [refactoring](), [testing](), [tests]() ### AI overview A six-step strategy for refactoring legacy code by breaking dependencies, using characterization and other testing techniques, achieving test coverage, and then changing the code. ### Source excerpt The art of making your code testable, testing it effectively, and refactoring it like a pro ## Parameterized Android Tests with Burst 2.0 DevFeed: [Parameterized Android Tests with Burst 2.0]() Original publisher: [Read original article]() Author: Sam Edwards Published: 2024-10-31T15:52:32Z Content type: tutorial Language: en Sources: [Handstand Sam]() Topics: [Android](), [Kotlin Multiplatform](), [Kotlin](), [Compiler](), [Test coverage](), [APK](), [Firebase](), [Gradle]() Tags: [analysis](), [android](), [apk](), [firebase](), [gradle](), [instrumentation](), [kotlin](), [kotlin-compiler](), [kotlin-multiplatform](), [updates]() ### AI overview The article explains how Burst 2.0, a Kotlin Compiler Plugin, enables parameterized tests for Kotlin Multiplatform and Android instrumentation tests. It reports that the tests compile and execute successfully from the command line, while noting IDE support issues and a use case for statically computing test names for sharding. ### Source excerpt Parameterized tests allow you to write a test once, but allow it to be called with multiple parameters. This means it is creating more methods than you've written, but without you having to write and maintain each one individually. Here is a trivial example of writing a single test with TestParameterInjector, but having it run [...] ## Introducing: Extensive AppSec visibility with Snyk Analytics DevFeed: [Introducing: Extensive AppSec visibility with Snyk Analytics]() Original publisher: [Read original article]() Author: Seth Rosen; Nastasha Casale Published: 2024-10-17T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Application Security](), [Exposure Management](), [Test coverage](), [Vulnerabilities](), [Artificial Intelligence](), [genai](), [Code](), [code productivity]() Tags: [ai](), [analytics](), [application-security](), [awareness](), [blog](), [code](), [developer-productivity](), [devops](), [devsecops](), [exposure-management](), [genai](), [megawatt](), [metrics](), [pmm](), [snyk](), [snyk-security-intel](), [vulnerabilities]() ### AI overview Snyk Analytics is presented as a comprehensive offering for AppSec leaders to track coverage, exposure, management, and prevention metrics. The article discusses measuring application security effectiveness, scaling secure development across developers and applications, and addressing the increased vulnerability risks associated with AI-generated code and AI assistants. ### Source excerpt Snyk Analytics is a comprehensive new offering that lets AppSec leaders improve program health by tracking coverage, exposure, management, and prevention metrics. ## Introducing the ASPM Masterclass DevFeed: [Introducing the ASPM Masterclass]() Original publisher: [Read original article]() Author: Erin Cullen Published: 2024-03-12T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Application Security](), [Security](), [Incident response](), [Test coverage](), [Learning]() Tags: [acquisition](), [application-security](), [aspm](), [blog](), [course](), [devops](), [devrel](), [devsecops](), [enablement](), [executive](), [learning](), [megawatt](), [related-content](), [security](), [snyk](), [webinar]() ### AI overview Snyk introduces the Unlocking AppSec Excellence masterclass series, which teaches application security leaders how to use application security posture management (ASPM) to build risk-based AppSec programs. The six chapters cover ASPM fundamentals, visibility and coverage, risk-based planning, incident response, metrics and KPIs, and team culture. ### Source excerpt Snyk's latest masterclass series, Unlocking AppSec Excellence, aims to educate the market on ASPM and how application security leaders can use it to build an effective risk-based AppSec program. ## AppSec Maturity Models DevFeed: [AppSec Maturity Models]() Original publisher: [Read original article]() Author: Daniel Berman Published: 2024-03-08T00:00:00Z Content type: tutorial Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Application Security](), [Security](), [Development](), [sdlc](), [Test coverage]() Tags: [application-security](), [article](), [awareness](), [compliance](), [how-to](), [learn](), [measurement](), [megawatt](), [metrics](), [reports](), [sdlc](), [secrel](), [security](), [standard]() ### AI overview This article explains how application security maturity models help organizations assess their current security posture, define goals, track progress with concrete metrics, and support continuous improvement. It covers their benefits for establishing standards, tailoring security efforts, building an AppSec program across the application library and SDLC, identifying improvement opportunities, generating reports, and demonstrating compliance. ### Source excerpt Learn what to include in your application security maturity model and how to assess your current level of application security maturity. ## Measuring the impact of your reliability work with reports DevFeed: [Measuring the impact of your reliability work with reports]() Original publisher: [Read original article]() Author: Andre Newman Published: 2024-02-06T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Resilience](), [Test coverage](), [Containers]() Tags: [blog](), [blog-post](), [gremlin](), [report](), [resilience](), [testing]() ### AI overview Gremlin's built-in Reliability, Team Risk, and Team Score reports help teams measure reliability progress, identify unresolved risks, evaluate testing coverage, and prioritize improvements such as redundancy, failover, scaling, and dependency resilience. ### Source excerpt Learn how Gremlin's built-in reporting tools track your reliability work, find high-priority reliability risks in your environment, and demonstrate your progress towards greater reliability. ## How I use Mutation Testing to Drive Good Test Case Coverage DevFeed: [How I use Mutation Testing to Drive Good Test Case Coverage]() Original publisher: [Read original article]() Author: Aleksander Jaworski Published: 2023-12-05T15:05:18Z Content type: tutorial Language: en Sources: [AKJAW]() Topics: [mutation-testing](), [Test coverage](), [Testing](), [Software Engineering]() Tags: [automated](), [bugs](), [development](), [mutation-testing](), [software](), [testing](), [tests]() ### AI overview The article explains how mutation testing evaluates test suites by changing production code logic. If tests still pass after a mutation, the test suite may be missing a case that detects the change. ### Source excerpt Automated testing is important for efficient software development, catching bugs within minutes and saving valuable developer time. Mutation Testing validates test suites by altering production code logic. When tests pass despite code mutations, it signals missing test cases. ## Notes from the "Test Driven Development by example" book DevFeed: [Notes from the "Test Driven Development by example" book]() Original publisher: [Read original article]() Author: Vadzimv Dev Blog Published: 2022-04-07T10:00:00Z Content type: opinion Language: en Sources: [vadzimv Dev Blog]() Topics: [Test-driven development](), [Testing](), [Test coverage](), [Refactoring](), [modules]() Tags: [development](), [refactoring](), [tdd](), [testing](), [tests]() ### AI overview Personal notes on Kent Beck's Test Driven Development: By Example, covering how automated tests can reduce stress and errors, how TDD influences testing, and techniques for improving test coverage through simplification and refactoring. ### Source excerpt My notes after reading the Test Driven Development: By Example book ## SiliFuzz: Fuzzing CPUs by proxy DevFeed: [SiliFuzz: Fuzzing CPUs by proxy]() Original publisher: [Read original article]() Author: Ruslan Cheremin (noreply@blogger.com) Published: 2021-11-02T12:33:00Z Content type: opinion Language: ru Sources: [\>рабочие заметки]() Topics: [Fuzzing/Fuzz testing](), [cpu](), [Test coverage](), [Google]() Tags: [cpu](), [fuzzing](), [google](), [tag-e34f6dec12c4](), [tag-e932065bc8da]() ### AI overview The article discusses SiliFuzz, a Google research project that uses fuzzing to continuously test server CPUs for hardware errors. It describes generating instruction-sequence tests, comparing processor results to establish expected behavior, quarantining machines with suspicious results, and using coverage-guided generation to improve test diversity. ### Source excerpt Недавно писал про статью инженеров гугла об аппаратных дефектах микропроцессоров (Cores that don't count) Там констатировалось, что такие дефекты есть, и их не так уж мало - но что с этим делать обсуждалось только гипотетически. SiliFuzz: Fuzzing CPUs by proxy1 - продолжение этой темы. Авторы задались целью создать механизм непрерывного тестирования парка серверов на аппаратные ошибки. ## Tests Under the Magnifying Lens DevFeed: [Tests Under the Magnifying Lens]() Original publisher: [Read original article]() Published: 2021-02-02T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Test coverage](), [engineering-culture](), [Tooling](), [Android](), [data](), [CRUD](), [data-processing](), [Refactoring](), [Backstage](), [Cypress](), [GitHub](), [Google]() Tags: [android](), [automation](), [backend](), [backstage](), [data](), [devxp](), [engineering](), [flaky](), [frontend](), [infrastructure](), [refactoring](), [test-coverage](), [testing](), [tooling]() ### AI overview SoundCloud describes an effort to improve testing infrastructure by aggregating test data across repositories, teams, and features. The proposed workflow treats build artifacts and test reports as data for analyzing test-suite health, retries, execution times, flakiness, pipeline costs, and developer waiting times, with the goal of guiding test fixes and refactoring. ### Source excerpt Testing is at the heart of engineering practices at SoundCloud. We strive to build well-balanced test pyramids within our code repositories... ## Fuzzing | Teleport OSS | Ada Logics DevFeed: [Fuzzing | Teleport OSS | Ada Logics]() Original publisher: [Read original article]() Author: info@goteleport.com (Adam Korczynski, Andrew Lytvynov) Published: 2020-12-20T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [Fuzzing/Fuzz testing](), [Go Language](), [Security](), [Development](), [Open Source](), [Test coverage](), [Google](), [test](), [C](), [C++]() Tags: [bugs](), [c](), [c-plus-plus](), [code](), [coverage](), [crash](), [development](), [examples](), [fuzzing](), [go](), [google](), [harness](), [oss](), [quality](), [security](), [test]() ### AI overview This article explains how Teleport integrated continuous fuzzing with help from Ada Logics. It describes building initial fuzzers, integrating Teleport with Google's OSS-Fuzz, and using go-fuzz to generate randomized inputs and explore code through coverage guidance. It also discusses crash-related bugs that fuzzing can find in Go projects. ### Source excerpt A fuzzer is a program that passes randomized data to an entrypoint of a target application. The goal is to stress test the target application. [Next page]()