# test-coverage A software testing metric used to identify untested parts of a codebase. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Rider and ReSharper 2026.2.2 Are Out! DevFeed: [Rider and ReSharper 2026.2.2 Are Out!]() Original publisher: [Read original article]() Author: Alexander Kurakin Published: 2026-09-16T14:12:44Z Content type: release Language: en Sources: [The JetBrains Blog]() Topics: [rider](), [resharper](), [AI-assisted coding](), [test-coverage]() Tags: [2026](), [ai-agent-hooks](), [ai-agents](), [code-coverage](), [coverage](), [hooks](), [jetbrains](), [macos](), [mcp](), [net](), [net-tools](), [releases](), [resharper](), [rider](), [update]() ### AI overview JetBrains releases Rider, ReSharper, and .NET tools 2026.2.2, adding an AI Agent Setup widget in Rider, more targeted hook feedback for coding agents, TUnit coverage support, and fixes including a macOS freezing issue. ### Source excerpt We've released version 2026.2.2 of ReSharper, Rider, and .NET tools. You can install this update from inside the tools themselves, through the Toolbox App, or on our website. Here's what's new in this update. Rider 2026.2.2 AI Agent Setup widget We've recently added a wide range of features to help you work with coding agents [...] ## 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. ## TDD inside the agent loop - theater or actual value? DevFeed: [TDD inside the agent loop - theater or actual value?]() Original publisher: [Read original article]() Author: Martin Fowler (martin@martinfowler.com) Published: 2026-08-11T11:39:00Z Content type: article Language: en Sources: [Martin Fowler]() Topics: [Test-driven development](), [Large Language Model](), [Artificial Intelligence](), [mutation-testing](), [test-coverage]() Tags: [agents](), [ai](), [claude](), [development](), [llm](), [testing]() ### AI overview This exploratory evaluation examines whether having an AI coding agent follow a test-driven development workflow produces better results than a non-TDD workflow. Across small, medium, and larger greenfield business-logic tasks, the reported results showed no clearly discernible difference in outcome quality or mutation scores; in some cases, the non-TDD solutions were judged slightly better in design and test quality. ### Source excerpt My colleagues at Thoughtworks tend to be big fans of Test-Driven Development, and many people in the industry advocate telling LLM agents to use TDD when building software. Birgitta Böckeler was curious if this really makes a difference, so conducted a few experiments. more... ## Porting Django to Go with AI Without the Naive Rewrite DevFeed: [Porting Django to Go with AI Without the Naive Rewrite]() Original publisher: [Read original article]() Published: 2026-07-28T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Django](), [Go Language](), [Artificial Intelligence](), [migration](), [Testing](), [test-coverage](), [Refactoring](), [proxy]() Tags: [ai](), [claude](), [copilot](), [django](), [go](), [migration](), [proxy](), [refactoring](), [test-coverage](), [testing]() ### AI overview The article argues that porting a Django API to Go with AI requires strong engineering foundations rather than line-by-line translation. It recommends tests, production-shaped traffic, clear module boundaries, code review, and incremental rollout mechanisms to establish behavioral parity and reduce migration risk. ### Source excerpt . [Porting Django to Go with AI Without the Naive Rewrite](porting-django-to-go-with-ai-cover... ## A Gradle Module Structure for Clear Boundaries, Faster Builds, and Test Coverage DevFeed: [A Gradle Module Structure for Clear Boundaries, Faster Builds, and Test Coverage]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2026-07-15T13:38:11Z Content type: article Language: en Sources: [Blogs on Ryan Harter]() Topics: [Gradle](), [build times](), [modules](), [test-coverage](), [Android Gradle Plugin](), [Kotlin]() Tags: [android-gradle-plugin](), [build](), [build-times](), [gradle](), [kotlin](), [modules](), [test-coverage]() ### AI overview The article describes a Gradle module convention that separates each feature's public API from its implementation. The author says this structure reduced build times and coupling between features while helping enforce test coverage, with Android Gradle Plugin support making a separate test-fixtures module unnecessary. ### Source excerpt Flattening my Dependency Graph Jesse Wilson Jesse explores a Gradle module structure that he likes. Read now ➡ I liked this not-so-recent post from Jesse Wilson, which outlines a Gradle module convention that prioritizes clear public/private boundaries to support encapsulation and build speed. The approach, adapted from one presented by Ralf Wondratschek, also happens to closely resemble one that I helped institute at Dropbox shortly after I joined four and a half years ago. ## Mutation testing comes to DAML DevFeed: [Mutation testing comes to DAML]() Original publisher: [Read original article]() Author: "Kamil Chmielewski" Published: 2026-07-08T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [mutation-testing](), [test-coverage](), [Authorization](), [Code](), [Open Source]() Tags: [applications](), [blockchain](), [bug](), [code](), [development](), [mutation-testing](), [open](), [open-source](), [production](), [test-coverage](), [testing](), [tool-release]() ### AI overview Mewt, an open-source mutation-testing engine, now supports DAML, the language used for Canton Network applications. The article explains how mutation testing exposes gaps that ordinary coverage reports can miss by generating modified versions of code and checking which changes survive the existing test suite. ### Source excerpt In April we released Mewt, our open-source mutation-testing engine that finds the gaps in your test suite. Today we're expanding it with support for DAML, the language Canton Network applications are written in. Mewt now reads DAML, generates several classes of mutants (including two built for DAML's authorization primitives), and runs them through your existing test suite to count how many mutants survive. If you want to try it, simply install Mewt from the repository, point a mewt.toml at your project and its test command, and use mewt run. For a team shipping DAML to production, that count is what a passing test run is actually worth: it puts a number on how much your suite checks, whereas a green run on its own does not. Why DAML's coverage reports lie Test coverage is the most reassuring lie in smart-contract development. Hitting 100% line coverage tells you the test runner walked the code; it does not tell you whether any test would fail if that code stopped doing what it is supposed to. We have been grading test harnesses by how many mutants they kill since at least 2019, and our primer on finding the bugs your tests don't catch shows how a green suite can still miss the bug that matters. DAML's built-in coverage measures execution at the template and choice level: which templates were created and which choices were exercised over the test run. It reports whether each choice was exercised, not what happened inside it. A test that exercises a choice once and asserts nothing about the result reports that choice as covered. The report prints the same green percentage whether the test verifies the outcome or discards it. How mutation testing works Instead of asking whether your tests reached the code, mutation testing grades your tests by sabotaging that code. The engine generates mutants, copies of the code that each carry one small deliberate change: a flipped comparison, a removed branch, a dropped party. It then runs your test suite against each one. A mutant ## How Monk migrated 100+ workflows from Inngest to Temporal DevFeed: [How Monk migrated 100+ workflows from Inngest to Temporal]() Original publisher: [Read original article]() Author: Francesco Coacci Published: 2026-06-16T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [migration](), [Orchestration](), [business logic](), [test-coverage]() Tags: [async](), [automation](), [business-logic](), [community](), [coverage](), [migration](), [orchestration](), [pull-request](), [workflows]() ### AI overview Monk describes migrating more than 100 live workflows from Inngest to Temporal incrementally, using reversible pull requests, parallel runtimes, feature-flagged cutovers, and no migration freeze. The article explains how this approach kept each workflow coherent and recoverable during the transition. ### Source excerpt Monk migrated 100+ live workflows from Inngest to Temporal with one reversible PR at a time all while avoiding freezes and rewrites. Here's how. ## TestParameterInjector introduces an idiomatic Kotlin API DevFeed: [TestParameterInjector introduces an idiomatic Kotlin API]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-25T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Kotlin](), [Testing](), [unit tests](), [test-coverage](), [Java](), [Open Source]() Tags: [java](), [junit4](), [junit5](), [kotlin](), [open-source](), [parameterized-tests](), [test-coverage](), [testing](), [testparameterinjector](), [unit-tests]() ### AI overview Google announces KotlinTestParameters, a Kotlin-only API for TestParameterInjector. It uses Kotlin default function arguments to make parameterized tests type-safe, concise, and compatible with refactoring tools, avoiding string-based YAML maps and verbose provider classes. ### Source excerpt by Jens Nyman, TestParameterInjector Team In March 2021, we announced the open source release of TestParameterInjector: a simple but powerful parameterized test runner for JUnit4. In September 2022, we followed up with JUnit5 support, bringing our framework to developers who had moved on to the Jupiter API. We're excited to announce our biggest update yet for our Kotlin users: KotlinTestParameters. The de facto standard for parameterized testing When we first introduced TestParameterInjector, we shared a graph showing its rapid adoption within Google. Over the past few years, that trajectory has continued to a point where TestParameterInjector is the de facto parameterized test framework. Usage of all other alternative frameworks continues to steadily decline, while TestParameterInjector's adoption keeps growing rapidly. It has fundamentally lowered the barrier to writing data-driven unit tests, empowering Googlers and open source developers alike to maximize test coverage with minimal boilerplate. We believe its ubiquity internally is a strong testament to its reliability and utility for the broader developer communities. The Kotlin challenge As Kotlin's popularity has surged, developers have naturally been writing more of their TestParameterInjector tests in Kotlin. However, specifying explicit test values in Kotlin historically meant falling back to Java-centric paradigms. If you wanted to provide specific values to a test, you typically had three options, none of which felt truly idiomatic in Kotlin: @TestParameter({"123", "456"}): This relies on string arrays, limiting you to a subset of types that the string parsing supports. @TestParameters: This allows for more complex sets of data, but relies on YAML strings (e.g.,"{age: 17, expectIsAdult: false}"). These strings however are not type-safe, and are completely ignored by IDE refactoring tools. Provider classes: For complex types that couldn't be easily represented in strings, you have to write Provider classe ## How Virgin Atlantic ships faster with Codex DevFeed: [How Virgin Atlantic ships faster with Codex]() Original publisher: [Read original article]() Published: 2026-05-22T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [codex](), [App](), [test-coverage](), [Code](), [Front end](), [Figma]() Tags: [app](), [code](), [codex](), [developers](), [engineering](), [figma](), [scrum](), [test-coverage]() ### AI overview Virgin Atlantic used Codex to deliver a revamped mobile app during the Christmas travel rush, achieving near-complete unit test coverage and zero P1 defects at launch. The team also used Codex to accelerate legacy-code refactoring and build a front-end application from a Figma prototype. ### Source excerpt How Virgin Atlantic used Codex to ship its revamped mobile app on a fixed holiday travel deadline, reaching near-total unit test coverage and zero P1 defects. ## How we automatically test the world's most secure Linux distribution DevFeed: [How we automatically test the world's most secure Linux distribution]() Original publisher: [Read original article]() Published: 2026-05-01T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [test-coverage](), [chainguard os](), [Linux](), [chainguard containers]() Tags: [chainguard](), [chainguard-containers](), [chainguard-os](), [chainguard-packages](), [chainguard-testing](), [linux](), [test-coverage]() ### AI overview Chainguard OS has achieved 100% test coverage across its package and subpackage catalog. The automated tests execute software, verify behavior, and test service lifecycles across x86_64 and aarch64 packages before release. ### Source excerpt Chainguard OS achieves 100% package test coverage, verifying every component runs correctly to make rolling updates secure, reliable, and enterprise-ready. ## One Decade Later: Revisiting Five Front-End Kung Fu Moves DevFeed: [One Decade Later: Revisiting Five Front-End Kung Fu Moves]() Original publisher: [Read original article]() Published: 2026-04-30T23:26:34Z Content type: opinion Language: en Sources: [Ariya Hidayat]() Topics: [Front end](), [Web Development](), [JavaScript](), [Testing](), [test-coverage](), [ci](), [Instrumentation](), [ESLint](), [Git](), [web-standards]() Tags: [browser](), [code-coverage](), [continuous-integration](), [coverage](), [engineering](), [eslint](), [firefox](), [front-end](), [git-hooks](), [javascript](), [testing](), [web-standards]() ### AI overview A retrospective revisits front-end engineering techniques presented at a JavaScript meetup ten years earlier. It discusses git hooks, code complexity, code coverage, and cross-browser testing, explaining how common tools and modern workflows have changed their practical use. ### Source excerpt Exactly ten years ago, I gave a talk at the SF JavaScript meetup titled 5 Kung Fu Moves for Front-End Heroes. A full decade later, I found myself wondering: are these techniques still the secret sauce for modern front-end engineering, or have they been rendered obsolete by time? ## What Happened When We Treated AI Like an Engineering Teammate DevFeed: [What Happened When We Treated AI Like an Engineering Teammate]() Original publisher: [Read original article]() Author: Global Technology Published: 2026-04-28T13:23:51Z Content type: opinion Language: en Sources: [McDonald's Technical Blog - Medium]() Topics: [Artificial Intelligence](), [AI Engineering](), [maintenance](), [Security](), [Cloud](), [test-coverage](), [Documentation](), [Framework]() Tags: [agent](), [ai](), [ai-agent](), [ai-engineering](), [autonomous](), [cloud](), [development](), [documentation](), [maintenance](), [platform-engineering](), [security](), [software-engineering](), [test-coverage](), [the-result](), [velocity]() ### AI overview The Restaurant Topology Management team used an AI-powered, agent-based engineering assistant within its development workflows to handle repetitive maintenance work, including configuration updates, security patches, framework modernization, test coverage, and documentation. The article reports 20% faster sprint velocity, security updates completed twice as fast, and modernization delivered up to 10 times faster. ### Source excerpt How an AI engineering assistant boosted sprint velocity by 20% and modernized services up to 10x faster. by: Sumedha Shenoy, Director, Engineering Tech Lead, and Kamal Jackson, Sr Manager, Engineering Tech Lead Quick Bytes: A growing backlog of essential but repetitive "glue work" was slowing the Restaurant Topology Management (RTM) team's ability to modernize and deliver new features By treating an AI engineering assistant as an autonomous teammate -- not a chatbot -- the team offloaded end-to-end maintenance tasks at scale The result was 20% faster sprint velocity, security updates completed twice as fast, and modernization work delivered up to 10x quicker without sacrificing quality In fast-moving software environments, critical but repetitive "glue work" like configuration updates, security patches, and documentation often compete with time that could be spent delivering new features. For the Restaurant Topology Management (RTM) team -- who build and maintain the cloud-based platform that enables markets to create and deploy consistent restaurant device configurations -- this maintenance workload had grown quietly over time and began to limit the team's ability to innovate. To regain momentum and address mounting operational debt, the team turned to an AI-powered, agent-based engineering assistant embedded into our standard development workflows, capable of handling complex, repetitive tasks. The challenge: The "un-fun" backlog Before piloting the AI assistant, the RTM team was managing maintenance tasks that had persisted across multiple sprints: Security updates: Enhancing automated scanning workflows to maintain a strong security posture Framework modernization: Updating services to align with the team's current application framework Test coverage improvements: Strengthening unit test consistency across services Documentation updates: Refreshing internal service documentation to support smoother onboarding and troubleshooting This maintenance work was important b ## Trailmark turns code into graphs DevFeed: [Trailmark turns code into graphs]() Original publisher: [Read original article]() Author: "Scott Arciszewski" Published: 2026-04-23T12:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Graphs](), [mutation-testing](), [Claude](), [Code](), [Claude Code](), [test-coverage](), [Tree-sitter](), [Python]() Tags: [ai](), [claude](), [claude-code](), [code](), [graphs](), [mutation-testing](), [open-source](), [python](), [research-practice](), [software](), [testing](), [tool](), [tool-release]() ### AI overview Trailmark is an open-source library that parses source code into queryable call graphs and exposes them through a Python API that Claude skills can call. The article explains how graph-level reasoning can help analyze codebases, triage surviving mutation-testing mutants by security relevance, and support Claude Code skills for tasks such as test vector generation and protocol diagramming. ### Source excerpt We're open-sourcing Trailmark, a library that parses source code into a queryable call graph of functions, classes, call relationships, and semantic metadata, then exposes that graph through a Python API that Claude skills can call directly. Install it now: uv pip install trailmark "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." John Lambert's widely cited observation about network security applies just as well to AI-assisted software analysis. When Claude reasons about a codebase, it reasons about lists: findings from static analyzers, surviving mutants from mutation testing, and line-by-line coverage reports. But the question that actually matters is a graph question: can untrusted input reach this code, and what breaks if it's wrong? We built Trailmark to answer that question. It gives Claude a graph to think with instead of a list. We're also releasing eight Claude Code skills we've built on top of it, designed for mutation triage, test vector generation, protocol diagramming, and more. When lists fall short Mutation testing is a great example of a method that benefits from graph-level reasoning. It's one of the best ways to measure test quality. It makes small changes to your source code (e.g., swapping a < for <=, replacing + with -) and checks whether your tests catch the difference. Mutants that survive reveal gaps in your test suite that code coverage metrics might miss. The downside is that a mutation testing run on a real codebase can produce hundreds of surviving mutants of varying significance. This is very much a list. Some surviving mutants are equivalent: the mutation doesn't change the program's behavior because of structural or mathematical constraints that the mutation testing tool can't see. Some are in dead code; some are in error message formatting; some are in the finite field arithmetic that underpins every cryptographic operation in your library. A flat list of surviving mutants doesn't tell you ## How Big Tech Interview Decisions and Rounds Work DevFeed: [How Big Tech Interview Decisions and Rounds Work]() Original publisher: [Read original article]() Published: 2026-04-21T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Code](), [Architecture & Design](), [test-coverage](), [Scalability]() Tags: [api-integration](), [bug](), [career](), [clean-code](), [dsa](), [faang](), [interview](), [interviews](), [system-design](), [tech](), [test-coverage]() ### AI overview The article explains how big tech interviews are evaluated. Interviewers assess specific signals independently across coding, system design, and project-focused rounds, then discuss the combined feedback in a panel. Communication, code quality, edge-case handling, problem-solving instincts, scalability, and trade-off analysis can affect the decision, not just whether a problem is solved. ### Source excerpt Having worked at a few big tech companies and having interviewed candidates for them as well, here are some things I wish more candidates knew going in. How decisions are actually made Each interviewer is assigned a round and for every round, there are specific signals they need to collect... ## Why the Author Is Skeptical of Test-Driven Development DevFeed: [Why the Author Is Skeptical of Test-Driven Development]() Original publisher: [Read original article]() Author: January Published: 2026-01-29T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [Test-driven development](), [Testing](), [test-coverage]() Tags: [software-testing](), [tdd](), [test-coverage](), [testing](), [tests](), [unit-test]() ### AI overview The author argues that test-driven development can provide useful rapid feedback and test coverage, but warns that it may shape code around testability and cannot ensure that tested behavior matches actual software requirements. ### Source excerpt I've gotten a lot of flack throughout my career over my disdain towards test-driven development (TDD). I have met a lot of people who swear by it! And, I have also met a lot of people who insisted that I adopt it, too, often with the implied threat of appealing to my boss if appealing to me didn't work. The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some code they want to write, observes the new test fail, and then one writes the implementation, iterating on it until the test passes. The advantage of this approach is, first, to ensure that your codebase is adequately covered by testing, and, second, to provide you a rapid feedback loop to assist in your work. I have often found elements of TDD to be quite useful. Using a unit test or something similar to provide an efficient rapid feedback loop is a technique which I have employed many times. However, I am and have always been skeptical of the cult which arises around automated software testing and in particular TDD. A lot of people adopt an unquestioning loyalty to TDD, building tools and practices and vibes around the idea. It's often too much. The flaw with TDD is that, while it ensures that you have a test for every function you write, it also exerts an influence on the tested codebase, shaping the code to be as "testable" as possible, which only sometimes leads to better code. Moreover, TDD has no means of ensuring that the behavior that your tests verify is the right behavior for your software to have. Software with a thousand passing tests and 100% test coverage could be doing whatever the user or the business or whatever needs it to, but it could just as easily not meet the requirements in spite of those comprehensive tests - and in any case it gives you confidence in your work, which may or may not be misplaced. The cult of TDD exploits the fact that TDD is very good at making you feel like a good, diligent programmer. That rapid fee ## How The New York Times is scaling Unit Test Coverage using AI Tools DevFeed: [How The New York Times is scaling Unit Test Coverage using AI Tools]() Original publisher: [Read original article]() Author: The NYT Open Team Published: 2026-01-13T18:51:55Z Content type: article Language: en Sources: [New York Times]() Topics: [Artificial Intelligence](), [test-coverage](), [unit test](), [Testing](), [Development](), [Web app](), [React]() Tags: [ai](), [ai-tools](), [code](), [coverage](), [development](), [reliability](), [scaling](), [software](), [test-coverage](), [testing](), [unit-test](), [unit-testing]() ### AI overview The New York Times describes using AI tools to expand unit-test coverage across its News site. The agents improved efficiency and coverage on critical code, but required strict human supervision and human review of the generated tests. ### Source excerpt How AI tools are helping our software engineers write better tests at scaleIllustration by Nick Little By Eric Chima and Leonardo Quixadá At The New York Times, we're all excited to build fresh new experiences that delight our users. Our product managers are driven to find new ways to get our work in front of our audience and build reader engagement. Our engineers are motivated to solve unique technical challenges. And just when you think all that work is on track, breaking news strikes and all of our plans change at once. With all that going on, who could blame us if our test coverage couldn't quite keep up? Like every engineering organization, The Times deals with routine maintenance tasks: updating dependencies, cleaning up old code, maintaining accessibility standards, and, yes, building testing into all of our products. Our engineers are committed to quality, but when you work at the speed of news, there's always a new issue that needs to be addressed. Fortunately, generative AI has arrived with the promise of tidying up after us, taking care of the busy work, and giving time back to our developers to focus on feature development. But how far can you trust it? Recently, one of our platform teams used AI tools to build out unit tests across our flagship product, the News site. This was an opportunity for our testing to catch up with our rapid development. Our goal was to improve the reliability of our web app, but also to evaluate AI products and determine how far we could push them to do work in bulk across our codebase. As expected, the agents required strict human supervision, but they improved our efficiency in writing tests and let us quickly expand coverage on some of our most critical code. AI accelerates, but humans test the tests Unit tests are a crucial part of the development process. The idea is to divide application code into small pieces and write tests for each, creating guardrails to ensure that changing one piece of the site doesn't impact the r ## Using Mutation Testing to Evaluate Test Suite Effectiveness DevFeed: [Using Mutation Testing to Evaluate Test Suite Effectiveness]() Original publisher: [Read original article]() Author: Andres Sacco Published: 2025-12-04T02:02:10Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [mutation-testing](), [Testing](), [test-coverage](), [Code]() Tags: [2025](), [code](), [code-coverage](), [effective](), [mutation](), [mutation-testing](), [testing](), [tests]() ### AI overview The article explains why high code coverage does not necessarily indicate effective tests. It introduces mutation testing, which evaluates a test suite by making small controlled changes to source code and checking whether the tests detect those changes. ### Source excerpt Creating or modifying an application involves many aspects, such as following best practices and applying design patterns to solve everyday problems. After writing the code, developers usually add unit tests and rely on tools like Sonar to track metrics such as code coverage and highlight potentially untested areas. However, high test coverage does not guarantee [...] The post Test Your Test appeared first on JVM Advent. ## Automating Exhaustive Branch Coverage for Sealed Types in Kotlin DevFeed: [Automating Exhaustive Branch Coverage for Sealed Types in Kotlin]() Original publisher: [Read original article]() Author: Sean Amos Published: 2025-11-20T16:33:33Z Content type: tutorial Language: en Sources: [Wealthfront]() Topics: [Kotlin](), [Testing](), [Unit testing](), [test-coverage](), [Code quality]() Tags: [android](), [automation](), [code](), [code-quality](), [exhaustive](), [kotlin](), [sealed](), [sealed-classes](), [subtype](), [test-coverage](), [testing](), [unit-testing](), [wealthfront-engineering]() ### AI overview This article explains how to build an Exhaustive Test Runner for Kotlin sealed classes and interfaces. The approach ensures that functions accepting sealed parameters have at least one unit test for each subtype, including future subtypes added to the hierarchy. ### Source excerpt We take code correctness and code quality seriously at Wealthfront. One of the most effective ways we ensure that our code is correct is through rigorous unit testing and strong typing. In Kotlin, sealed classes and sealed interfaces offer a powerful tool to model restricted class hierarchies. They provide strong guarantees about the types in... Read more ## Google Summer of Code 2025 Results DevFeed: [Google Summer of Code 2025 Results]() Original publisher: [Read original article]() Author: Thomas Dinges Published: 2025-10-21T09:37:52Z Content type: article Language: en Sources: [Blender]() Topics: [Google](), [Code](), [Testing](), [test-coverage](), [cpu](), [GPU]() Tags: [2025](), [code](), [cpu](), [general-development](), [google](), [gpu](), [gsoc](), [technical](), [test-coverage](), [testing]() ### AI overview Blender's Google Summer of Code 2025 results article reviews work by eight contributors on the compositor, Video Sequence editor, mesh editing, sculpting, regression test coverage, and the Flamenco render manager. It notes that most changes had already been merged and were planned for Blender 5.0. ### Source excerpt See the outcome of the eight projects to be part of Google Summer of Code 2025. ## Keycloak JS 26.2.1 released DevFeed: [Keycloak JS 26.2.1 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-10-09T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [JavaScript](), [test-coverage](), [migration]() Tags: [bugfixes](), [idm](), [javascript](), [kerberos](), [keycloak](), [keycloak-js-release](), [ldap](), [migration-guide](), [openid-connect](), [release](), [saml](), [sso](), [test-coverage]() ### AI overview Keycloak JS 26.2.1 is a patch release following its separation from the main project release cycle. It includes an internal refactor, modern JavaScript language features, a new test suite with more comprehensive test coverage, bug fixes, and small enhancements, with no expected breaking changes for users. ### Source excerpt Highlights This release of Keycloak JS is the first release after our initial announcement to split if off from the main project release cycle. This release is the result of a large internal refactor to make the code more maintainable and make use of modern JavaScript language features, as well as to introduce a new test suite with more comprehensive test coverage. Even though much has changed under the hood, this is a patch releases, and there should be no breaking changes for users, only bugfixes and small enhancements. Upgrading Before upgrading refer to the migration guide for a complete list of changes. ## How to get fast, easy insights with the Gremlin MCP Server DevFeed: [How to get fast, easy insights with the Gremlin MCP Server]() Original publisher: [Read original article]() Author: Gavin Cahill Published: 2025-08-28T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [MCP Server](), [Model Context Protocol](), [Chaos Engineering](), [Large Language Model](), [test-coverage](), [Authorization](), [Containers](), [dashboards](), [Security](), [API keys]() Tags: [access-control](), [ai](), [api](), [api-keys](), [applications](), [chaos-engineering](), [chatgpt](), [claude](), [components](), [core](), [data](), [gremlin](), [hardening](), [how-to](), [insights](), [installation](), [llm](), [management](), [mcp](), [mcp-server]() ### AI overview The article explains how the Gremlin MCP Server connects an LLM client to the Gremlin API so teams can explore reliability-testing data and identify insights using natural-language prompts. It covers the client-server architecture, containerized deployment, security hardening, non-destructive API operations, dashboards, reporting, evaluation, and RBAC-based control of API keys. ### Source excerpt Find out how to quickly and easily uncover new reliability insights by using the Gremlin MCP Server and your favorite LLM. ## How Mocking Affects Software Design and Testability DevFeed: [How Mocking Affects Software Design and Testability]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-19T07:45:14Z Content type: tutorial Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Testing](), [Test-driven development](), [Refactoring](), [test-coverage]() Tags: [coverage](), [mocking](), [mongodb](), [refactoring](), [tdd](), [testing]() ### AI overview A recorded talk examines when mocks are useful, common misconceptions about mocking and TDD, and how excessive or poorly chosen mocks can constrain software design and testability. It discusses multi-mock tests, database mocking, and designing narrow seams around dependencies. ### Source excerpt If you've ever felt like your tests get in the way of refactoring, or like mocks make everything harder rather than simpler this stream is for you. ## Improving our Java SDK with Codex by OpenAI DevFeed: [Improving our Java SDK with Codex by OpenAI]() Original publisher: [Read original article]() Author: Ryan Cox Published: 2025-05-17T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [codex](), [Java](), [SDKs](), [OpenAI](), [bug](), [Refactoring](), [test-coverage](), [Development]() Tags: [agentic](), [announcements](), [automate](), [bug](), [bug-fixes](), [code-coverage](), [codex](), [contributions](), [development](), [documentation](), [github](), [java](), [open-source](), [openai](), [refactoring](), [sdk]() ### AI overview Temporal engineers describe using OpenAI's Codex to improve the Java SDK by fixing bugs, implementing features, increasing code coverage, adding documentation, and performing refactoring. They also used parallel background tasks and AGENTS.md files to prepare repositories for agentic contributions. ### Source excerpt Learn all about how the Temporal engineers used OpenAI's Codex to improve our Java SDK, automate bug fixes, and prepare for agentic contributions, plus, how part of Codex itself runs on Temporal. ## Node.js 22.8.0 (Current) DevFeed: [Node.js 22.8.0 (Current)]() Original publisher: [Read original article]() Published: 2024-09-03T13:51:48Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [Caching](), [JavaScript](), [test-coverage](), [V8](), [API]() Tags: [benchmark](), [caching](), [cross-platform](), [javascript](), [node-js](), [open-source](), [release](), [tooling]() ### AI overview Node.js 22.8.0 introduces an API for enabling on-disk code caching for subsequently loaded modules, including ESM support. The release also adds an uncified VM context option, configurable code-coverage thresholds, and several performance, networking, test-runner, build, and dependency updates. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. [Next page]()