# continuous integration Published articles for continuous integration. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Checks for safer review of rapidly generated TypeScript and React frontend code DevFeed: [Checks for safer review of rapidly generated TypeScript and React frontend code]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-09-01T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Front end](), [React](), [TypeScript](), [Artificial Intelligence](), [OpenAPI Specification](), [API](), [mutation-testing](), [Testing](), [Code]() Tags: [agent-experience](), [agentic-development](), [agents](), [ai](), [api](), [code](), [continuous-integration](), [dx](), [frontend](), [llms](), [mutation-testing](), [openapi](), [react](), [testing](), [typescript]() ### AI overview This article presents ten checks for making rapidly generated TypeScript and React frontend code safer to trust and cheaper to review. It covers API contracts, generated types, boundary validation, mutation testing, dead-code detection, and mandatory checks. ### Source excerpt Ten checks that catch what AI-written frontend code hides: contract codegen, boundary linting, mutation testing, and dead-code detectors. ## New: Finish Cypress Cloud runs faster with the Run Completion API DevFeed: [New: Finish Cypress Cloud runs faster with the Run Completion API]() Original publisher: [Read original article]() Published: 2026-08-26T18:51:15Z Content type: article Language: en Sources: [Cypress Blog]() Topics: [Cypress](), [Testing](), [API](), [CI/CD](), [Accessibility](), [ui]() Tags: [accessibility](), [api](), [continuous-integration](), [cypress](), [testing](), [ui]() ### AI overview The article introduces the Run Completion API for Cypress Cloud. It lets a run finalize immediately after test recording ends instead of waiting for additional test groups, helping workflows that depend on finalized pass/fail results complete sooner. ### Source excerpt Starting now, all Cypress Cloud plans can use the Run Completion API, allowing the Cypress Cloud run to finalize immediately at the end of test recoding, instead of staying open for new tests. Here's why that's important and how it can save you time. Cloud runs can have multiple groups of tests Cypress Cloud runs are often made up of many isolated cypress run groups. These may represent things like: * separate parallel machines * different browsers running the tests * different testing t ## Refactoring a SQL Table at Scale: Lessons from Harness CI DevFeed: [Refactoring a SQL Table at Scale: Lessons from Harness CI]() Original publisher: [Read original article]() Author: Moshe Tsur Published: 2026-08-06T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [Refactoring](), [Structured-data](), [Databases](), [SQL](), [Latency](), [API](), [ci]() Tags: [api](), [continuous-integration](), [harness](), [latency](), [refactoring](), [schema](), [sql]() ### AI overview Harness describes refactoring a flat SQL table used for CI test results into a normalized schema. The article reports reducing storage per row from 400 bytes to 28 bytes and making API latency constant at any scale. ### Source excerpt How Harness refactored a flat SQL table into a normalized schema, cutting storage per row from 400 bytes to 28 bytes and making API latency constant at any scal | Blog ## The Electron browser is being deprecated in Cypress DevFeed: [The Electron browser is being deprecated in Cypress]() Original publisher: [Read original article]() Published: 2026-07-10T15:15:58Z Content type: article Language: en Sources: [Cypress Blog]() Topics: [Cypress](), [Electron](), [Testing](), [browsers](), [Chromium](), [Continuous integration]() Tags: [browser](), [browsers](), [chrome](), [chromium](), [continuous-integration](), [cypress](), [edge](), [firefox](), [testing]() ### AI overview Cypress is deprecating its bundled Electron browser starting with Cypress 16.0.0 and plans to remove it in a future major version. The article explains that tests can produce inconsistent results in Electron compared with users' installed browsers, and recommends moving local and CI runs to installed browsers such as Chrome for Testing, Chrome, Firefox, or Edge. ### Source excerpt We're deprecating the Electron browser in Cypress, starting in Cypress 16.0.0, with removal in a future major version. After years of seeing inconsistent results between Electron and the browsers people actually use, we are standardizing on installed browsers for more reliable test results. ## Tuning Android build nodes for maximum throughput DevFeed: [Tuning Android build nodes for maximum throughput]() Original publisher: [Read original article]() Author: Chris Mathew Published: 2026-06-25T15:29:45Z Content type: tutorial Language: en Sources: [Wealthfront]() Topics: [Gradle](), [Amazon EC2](), [Android](), [ci](), [Processes]() Tags: [android](), [caching](), [ci](), [continuous-integration](), [ec2](), [gradle](), [infrastructure](), [performance](), [wealthfront-engineering]() ### AI overview This article explains how Wealthfront's Android team tuned Gradle for build workloads on Amazon m7i.8xlarge EC2 instances. It covers Gradle daemon configuration, JVM memory settings, parallel execution, build caching, and the choice to use single-use daemons for CI builds. ### Source excerpt Introduction Our Android team uses Gradle as our build tool of choice. Gradle offers lots of options for tuning its resource consumption, giving engineers an opportunity to optimize performance for running tasks on well-known hardware. In this post, we'll explore how the team tuned our Gradle setup for Amazon's m7i.8xlarge EC2 instances. General concepts Before... Read more ## Trust Factory DevFeed: [Trust Factory]() Original publisher: [Read original article]() Author: Kent Beck Published: 2026-06-02T13:33:57Z Content type: opinion Language: en Sources: [Software Design: Tidy First?]() Topics: [trust](), [Code](), [Testing](), [CI/CD](), [Continuous Deployment (CD)](), [observability](), [Refactoring]() Tags: [code](), [continuous-deployment](), [continuous-integration](), [observability](), [refactoring](), [testing](), [trust]() ### AI overview This commentary argues that software development practices can function as a "trust factory." It connects programmer testing, pairing, continuous integration, weekly planning, customer involvement, continuous deployment, refactoring, and observability with building trust among developers, customers, and teams. ### Source excerpt "We're accumulating code faster than we are accumulating trust." Sometimes a phrase just hits. ## 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? ## Leveraging AI to build a faster iOS CI system DevFeed: [Leveraging AI to build a faster iOS CI system]() Original publisher: [Read original article]() Author: Muhieddine EL Kaissi Published: 2026-04-21T18:16:01Z Content type: article Language: en Sources: [Thumbtack Engineering - Medium]() Topics: [CI/CD](), [Testing](), [iOS](), [AI-assisted coding]() Tags: [ai](), [ai-assisted-coding](), [ci-cd](), [continuous-integration](), [developer](), [developer-productivity](), [ios](), [ios-development](), [mobile](), [pipeline](), [testing]() ### AI overview Thumbtack describes Smart Test Selection, an iOS CI system that reduces pipeline time by running only tests relevant to each pull request. The article explains why parallelization stopped scaling, including node contention, large test suites, and slow snapshot and UI tests, while noting that AI-assisted coding could increase CI demand. ### Source excerpt Every iOS pull request at Thumbtack used to wait 30 to 40 minutes for Continuous Integration (CI) -- sometimes over an hour on Fridays. We built Smart Test Selection (STS) to cut that in half. Here's how. I'm a Senior Software Engineer on the iOS Infrastructure team. We own the CI/CD pipelines, build tooling, and shared frameworks that keep Thumbtack's apps shipping reliably. We also build AI-powered developer tooling -- 35+ AI Agent Skills, MCP integrations for Jenkins, Figma, Firebase, and Xcode -- that help the broader iOS team ship faster. Over the past few quarters, we built Smart Test Selection (STS), a system that reduces CI time by running only the tests that matter for each pull request. Why Full-Suite Testing Stopped Scaling Before STS, we had already optimized CI through parallelization -- running consumer, pro, and shared framework tests on separate nodes, and splitting snapshot tests across multiple simulator clones. But parallelization hit a ceiling. The more nodes we spread CI across, the more engineers had to wait for free nodes, cancelling out the speed gains. Snapshot tests dominated the suite but couldn't be split further without diminishing returns, and UI tests were inherently slow per-test. We needed a fundamentally different approach: run fewer tests, not run the same tests faster. Every iOS PR ran the full test suite for each affected app. We have three main targets -- a consumer app, a pro app, and a shared framework -- totaling 1,500+ test classes. The pipeline already skipped unaffected apps (a change to the consumer app would not run pro app tests), but within each affected app, every test ran regardless of what specifically changed. A one-line bug fix in one screen would trigger all 400+ tests for that entire app. This was becoming unsustainable. Human-generated code was already putting CI at the limit due to ever-increasing code size and test counts. We had increased our CI node count multiple times to keep up with demand, but each expansion ## The Design Process and Agile Development: Part 2 -- Collaborative Activities DevFeed: [The Design Process and Agile Development: Part 2 -- Collaborative Activities]() Original publisher: [Read original article]() Author: Daisy Mølving Published: 2026-01-16T06:00:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [Agile](), [User experience (UX)](), [Development](), [Software Engineering](), [Testing]() Tags: [agile](), [continuous-integration](), [design](), [development](), [experiential-design](), [teams](), [testing](), [user-experience]() ### AI overview This article explains how UX designers, product owners, and software developers can collaborate during an agile design process. It focuses on continuous discovery through stakeholder interviews, competitive and analogous research, user interviews, testing, and collaboration with developers on codebase, infrastructure, feasibility, and timelines. ### Source excerpt Updated 1/16/2026. Originally published 12/10/2024 As we talked about in Part 1 of this blog series, The Design Process and Agile Development: Part 1 -- Design Is Collaborative, the design process provides teams with the opportunity to join forces, paving the way for an integrated team of user experience (UX) designers, product owners, and agile software development to create a successful product. So where do you begin? You have a new project and an integrated team. You know that success can be achieved in close collaboration between your team members, each representing deep expertise in desirability, viability, and feasibility. But you need to determine which activities are most profitable for the team to put their heads together on and what their responsibilities should be. Find Out Together Finding Out is where it all starts, but it most certainly doesn't only happen at the start! We 'find out' in continuous cycles throughout the project, not just from our users, but also from our stakeholders and product and development teammates. After all, though the end product is ultimately for our end users, design is also influenced by viability, or the business, and feasibility, or the developers. So it makes sense to 'find out' collaboratively. You can do this through stakeholder interviews, competitive analysis and analogous research, user interviews and testing, and continuous integration (CI) tools. Stakeholder Interviews Stakeholder interviews are an early, integral step for determining what your stakeholders care about -- their hopes and fears, past project experiences that might drive their decision-making, key metrics they need to hit, and any assumptions they may have. Not only will you build rapport, you'll also learn how to engage your stakeholders through the design process. I've experienced that not all stakeholders have immediate faith in design, so understanding how they measure success and engaging with their success criteria throughout your work can be cruc ## Heroku AppLink: Now Using JWT-Based Authorization for Salesforce DevFeed: [Heroku AppLink: Now Using JWT-Based Authorization for Salesforce]() Original publisher: [Read original article]() Author: Vivek Viswanathan Published: 2025-12-11T16:00:53Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [JSON Web Tokens](), [Authorization](), [CI/CD](), [ci](), [Security](), [Microservice](), [OAuth]() Tags: [applink](), [authorization](), [ci-cd](), [continuous-deployment](), [continuous-integration](), [credentials](), [deployment](), [heroku](), [jwt](), [news](), [oauth](), [secrets](), [security](), [tokens]() ### AI overview Heroku AppLink now supports JWT-based authorization for Salesforce integrations. The update enables machine-to-machine authorization for automated CI/CD setup and reduces reliance on long-lived secrets and static credentials by providing on-demand tokens. ### Source excerpt Modern Continuous Integration/Continuous Deployment (CI/CD) pipelines demand machine-to-machine authorization, but traditional web-based flow requires manual steps and often rely on static credentials; a major security risk. Heroku AppLink now uses JWT Authorization to solve both: enabling automated setup and eliminating long-lived secrets. In today's evolving threat landscape, security attacks increasingly exploit systems that rely on [...] The post Heroku AppLink: Now Using JWT-Based Authorization for Salesforce appeared first on Heroku. ## Heroku GitHub Enterprise Integration enters closed pilot with GitHub App-based connections DevFeed: [Heroku GitHub Enterprise Integration enters closed pilot with GitHub App-based connections]() Original publisher: [Read original article]() Author: Alberto Sigismondi Published: 2025-12-10T16:00:09Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [CI/CD](), [Continuous Delivery (CD)](), [GitHub]() Tags: [continuous-delivery](), [continuous-integration](), [credentials](), [deployment](), [heroku](), [heroku-enterprise](), [heroku-pipelines](), [integration](), [news](), [security]() ### AI overview Heroku announces a closed pilot of its GitHub Enterprise Integration for Heroku Enterprise customers. The integration uses a dedicated GitHub App-based service identity instead of personal OAuth tokens to connect GitHub Enterprise Server or Cloud with Heroku deployment pipelines. ### Source excerpt We're excited to announce a significant enhancement to how Heroku Enterprise customers connect their deployment pipelines to GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud (GHEC). The new Heroku GitHub Enterprise Integration is now available in a closed pilot, offering a more secure, robust, and permanent connection between your code repositories and your Heroku apps. [...] The post Heroku GitHub Enterprise Integration: Unlocking Full Continuous Delivery for Enterprise Customers appeared first on Heroku. ## Speeding up Materialize CI DevFeed: [Speeding up Materialize CI]() Original publisher: [Read original article]() Published: 2025-08-07T22:00:00Z Content type: article Language: en Sources: [Dennis Felsing]() Topics: [ci](), [test](), [pull-requests]() Tags: [blog](), [blog-post](), [ci](), [continuous-integration](), [developers](), [integration](), [pipeline](), [programming](), [pull-requests](), [test](), [tests](), [work]() ### AI overview The article describes how the Materialize team significantly sped up its continuous integration test pipeline in July, particularly for pull requests requiring a build and full test run. The effort aimed to reduce developer waiting time as tests and code had increased CI duration. ### Source excerpt In the previous post I talked about how we test Materialize. This time I'll describe how I significantly sped up our Continuous Integration (CI) Test pipeline in July, especially for pull requests that require a build and full test run. The goal is to make developers more productive by reducing the time waiting for CI to complete. We always kept CI runtime in mind, but it still slowly crept up over the years through adding tests, the code itself growing larger, as well as hundreds of minor cuts adding up. Read the rest of the blog post over on the Materialize blog. ## Now in Android #120 DevFeed: [Now in Android #120]() Original publisher: [Read original article]() Author: Daniel Galpin Published: 2025-08-06T21:01:41Z Content type: article Language: en Sources: [Android Developers - Medium]() Topics: [Android](), [Beta channel](), [Android Studio](), [Artificial Intelligence](), [Google Play](), [CI/CD](), [Image]() Tags: [agentic-ai](), [android](), [android-development](), [android-studio](), [androidcanary](), [canary-release](), [continuous-integration](), [developer-preview](), [featured](), [google-play](), [now-in-android](), [pixel]() ### AI overview Now in Android #120 is a roundup of Android development updates covering the new Canary release channel, Agent Mode in Android Studio, Google Play changes including 16 KB Page Size requirements, Play Games updates, Android 16 devices, and Compose tips. ### Source excerpt Canary Channel, Agentic AI in Android Studio, 16 KB Pages, Policy Changes, Compose Tips, Play Games Welcome to Now in Android, your ongoing guide to what's new and notable in the world of Android development. This edition features the Android platform Canary Channel, the first release of Agentic AI in Android Studio, Play updates including 16 KB Page Size requirements and other policy changes, new capabilities around one-time purchases, Play Games Services v2, and Google Play Games on PC, I/O recaps on AI and dev productivity, next gen Samsung devices running Android 16, Compose tips, and more. https://medium.com/media/2034f6e8beea3e321d4483d4ee77ebdf/hrefhttps://medium.com/media/0247cb404c27e0b8725bc258c35923bc/href Most of the content of this post is available in the form of a video or podcast, so feel free to watch or listen rather than read on. (Or do all three to help you remember! There won't be a quiz.) Evolving Android's early-access programs: Introducing the Canary channel 🐦 Android has introduced a new Canary release channel for its early-access programs, replacing the previous developer preview model. This channel provides earlier and more consistent access to in-development platform features throughout the year. The new Canary channel offers continuous, rolling over-the-air (OTA) updates for supported Pixel devices, addressing previous limitations where previews required manual flashing and the preview program ended once a platform version reached Beta, requiring manual flashing to enter it again for the next cycle. You can use the Canary channel to: Access new features and potential behavior changes in their earliest stages. Integrate builds into your Continuous Integration (CI) systems to identify app compatibility issues early. Download Canary SDKs through the SDK Manager and access builds via the Android Studio Canary channel for development and testing. The Canary channel operates in parallel with the existing Beta program. Canary builds are bleedin ## How we replaced the default K8s scheduler to optimize our Continuous Integration builds DevFeed: [How we replaced the default K8s scheduler to optimize our Continuous Integration builds]() Original publisher: [Read original article]() Author: Vadim Gusev Published: 2025-07-07T11:57:20Z Content type: article Language: en Sources: [Codefresh]() Topics: [Kubernetes](), [ci]() Tags: [clusters](), [codefresh](), [continuous-integration](), [devops](), [glossary](), [k8s](), [kubernetes](), [orchestration](), [pipeline](), [product-and-tools](), [scheduler]() ### AI overview Codefresh describes replacing the default Kubernetes scheduler for clusters running ephemeral Continuous Integration pipelines. The article explains how this workload differed from long-running applications and motivated a different approach to Kubernetes scheduling. ### Source excerpt The default Kubernetes scheduler works great when your cluster is destined for long running applications. At Codefresh we use our Kubernetes clusters for running Continuous Integration pipelines which means our workloads are ephemeral (they are discarded when a pipeline has finished). This allowed us to look at the Kubernetes scheduler from a different perspective and [...] The post How we replaced the default K8s scheduler to optimize our Continuous Integration builds appeared first on Codefresh. ## Golang and Let's Encrypt: a free software story DevFeed: [Golang and Let's Encrypt: a free software story]() Original publisher: [Read original article]() Published: 2025-06-26T01:41:49Z Content type: opinion Language: en Sources: [Tony Finch's blog]() Topics: [let's encrypt](), [free software](), [Pull Request](), [CASE](), [Testing](), [CI/CD]() Tags: [bug](), [continuous-integration](), [free-software](), [golang](), [let-s-encrypt](), [pull-request](), [review](), [testing]() ### AI overview The author recounts fixing a Let's Encrypt Boulder bug involving mail-domain validation as a newcomer to Golang. They describe relying on Let's Encrypt's cloud test setup, submitting a small pull request, and seeing it merged into production within a few days. ### Source excerpt Here's a story from nearly 10 years ago. the bug I think it was my friend Richard Kettlewell who told me about a bug he encountered with Let's Encrypt in its early days in autumn 2015: it was failing to validate mail domains correctly. the context At the time I had previously been responsible for Cambridge University's email anti-spam system for about 10 years, and in 2014 I had been given responsibility for Cambridge University's DNS. So I knew how Let's Encrypt should validate mail domains. Let's Encrypt was about one year old. Unusually, the code that runs their operations, Boulder, is free software and open to external contributors. Boulder is written in Golang, and I had not previously written any code in Golang. But its reputation is to be easy to get to grips with. So, in principle, the bug was straightforward for me to fix. How difficult would it be as a Golang newbie? And what would Let's Encrypt's contribution process be like? the hack I cloned the Boulder repository and had a look around the code. As is pretty typical, there are a couple of stages to fixing a bug in an unfamiliar codebase: work out where the problem is try to understand if the obvious fix could be better In this case, I remember discovering a relatively substantial TODO item that intersected with the bug. I can't remember the details, but I think there were wider issues with DNS lookups in Boulder. I decided it made sense to fix the immediate problem without getting involved in things that would require discussion with Let's Encrypt staff. I faffed around with the code and pushed something that looked like it might work. A fun thing about this hack is that I never got a working Boulder test setup on my workstation (or even Golang, I think!) - I just relied on the Let's Encrypt cloud test setup. The feedback time was very slow, but it was tolerable for a simple one-off change. the fix My pull request was small, +48-14. After a couple of rounds of review and within a few days, it was merged ## Scaling Technology with Architectural Principles DevFeed: [Scaling Technology with Architectural Principles]() Original publisher: [Read original article]() Author: Shane Gibb Published: 2025-01-08T01:18:36Z Content type: article Language: en Sources: [REA Group]() Topics: [scaling](), [Software Engineering](), [Development](), [Continuous Deployment (CD)](), [maintenance](), [Design system](), [CI/CD]() Tags: [code](), [continuous-deployment](), [continuous-integration](), [design-system](), [engineering](), [maintenance](), [scaling](), [tech]() ### AI overview REA Group describes how architectural principles developed through 25 years of growth guide its software engineering practices, including decision-making, system resilience, team agility, platform reuse, and continuous deployment. ### Source excerpt REA Group, a global company with 1,000+ digital product builders, developed architectural principles from 25 years of growth. ## On Long Term Software Development DevFeed: [On Long Term Software Development]() Original publisher: [Read original article]() Published: 2024-12-22T17:00:00Z Content type: opinion Language: en Sources: [Bert Hubert's writings]() Topics: [Development](), [Software](), [Open Source](), [CI/CD](), [Programming](), [Framework](), [Esolang]() Tags: [ci](), [continuous-deployment](), [continuous-integration](), [dependencies](), [development](), [framework](), [mastodon](), [open-source](), [programming](), [programming-languages](), [software]() ### AI overview An opinion article reflecting on long-term software development through a talk about the Dutch Electoral Board's open-source Abacus vote tabulation software. It contrasts continuously deployed, heavily tested services with safety-critical software that must remain stable for decades, and discusses dependencies, programming languages, and frameworks as long-term design choices. ### Source excerpt Recently the Dutch Electoral Board (where I am also a very part time advisor) invited me to do a talk reflecting on their open source Abacus vote tabulation software. Much software is now provided as a service, and is typically deployed continuously (CD, continuous deployment), surrounded by enough automated testing (CI, continuous integration) that we can be reasonably sure that a new revision is likely to at least work to some extent. ## Enforce Flexible Governance in GraphOS using Custom Checks DevFeed: [Enforce Flexible Governance in GraphOS using Custom Checks]() Original publisher: [Read original article]() Author: Samuel Collard Published: 2024-11-26T12:00:00Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphOS](), [API Governance](), [API Platform]() Tags: [api-governance](), [api-platform](), [business-logic](), [continuous-integration](), [graphos](), [graphql](), [schema](), [security-policies]() ### AI overview Apollo GraphOS supports custom schema checks that let organizations add business logic, security policies, and company-specific rules to the existing schema check workflow. The article introduces the governance use case and begins describing how to configure a custom check through an HTTPS endpoint. ### Source excerpt Apollo GraphOS now supports custom schema checks, a new feature that addresses API platform teams' demand for enhanced schema governance capabilities. This functionality allows organizations to integrate their own business logic, security policies, and rules into Apollo's existing schema check workflow, ensuring that every schema change adheres to company-specific standards. ## Testing applications with Pytest and NuttX DevFeed: [Testing applications with Pytest and NuttX]() Original publisher: [Read original article]() Author: John Lee Published: 2024-10-04T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [Testing](), [NuttX](), [Python](), [Espressif]() Tags: [apache](), [blog](), [continuous-integration](), [development](), [esp32](), [espressif](), [nuttx](), [pytest](), [python](), [tdd](), [testing]() ### AI overview A practical guide to using Pytest for high-level, on-target testing of applications running on the NuttX RTOS, including test environments, fixtures, parametrization, command-line arguments, and plugins. ### Source excerpt How Pytest is used for testing the NuttX RTOS on Espressif devices. ## Testing a React App in Chrome with Heroku CI DevFeed: [Testing a React App in Chrome with Heroku CI]() Original publisher: [Read original article]() Author: Julián Duque Published: 2024-09-24T20:11:00Z Content type: tutorial Language: en Sources: [Heroku]() Topics: [React](), [Heroku](), [ci](), [Playwright](), [Puppeteer](), [Headless Browser](), [Testing](), [Jest](), [web applications](), [JavaScript]() Tags: [browser](), [ci](), [continuous-integration](), [developer-tools](), [download](), [engineering](), [github](), [google-chrome](), [guide](), [heroku](), [javascript](), [jest](), [react](), [testing](), [unit-testing](), [web-applications]() ### AI overview This tutorial explains how to run end-to-end tests for a React application in Heroku CI using headless Chrome, Jest, and Puppeteer. It covers automating tests for a simple form-based application and configuring the application and test scripts for CI execution. ### Source excerpt When building web applications, unit testing your individual components is certainly important. However, end-to-end testing provides assurance that the final user experience of your components chained together matches the expected behavior. Testing web application behavior locally in your browser can be helpful, but this approach isn't efficient or reliable, especially as your application grows more [...] The post Testing a React App in Chrome with Heroku CI appeared first on Heroku. ## The CI Flake DevFeed: [The CI Flake]() Original publisher: [Read original article]() Published: 2024-08-15T22:00:00Z Content type: article Language: en Sources: [Dennis Felsing]() Topics: [ci](), [Docker Compose](), [debug](), [Python]() Tags: [bugs](), [ci](), [continuous-integration](), [debug](), [docker](), [docker-compose](), [integration](), [python]() ### AI overview The article investigates a rare flaky test failure in Materialize CI that became more frequent after tests moved from AWS to Hetzner Cloud. It documents attempts to diagnose the issue, including flushing a generated docker-compose.yaml file, reproducing the failure, and examining parallel execution and CI setup. ### Source excerpt I analyzed a flaky test failure in our Materialize CI today: $ docker compose up -d --scale default=0 default no such service: default mzcompose: error: running docker compose failed (exit status 1) I had seen this error already once or twice in the last year, but it was incredibly rare in our Continuous Integration (CI) runs, and never happened locally. As usual, there were more pressing product issues to debug, so I never looked into it. But last week I switched most of our CI tests to run on Hetzner Cloud instead of AWS to save some money. Suddenly this issue started occurring more often in CI, so my thinking was that it must somehow be timing-dependent. Before investigating my first instinct was that we are not writing the docker-compose.yaml file properly, which had already led to flaky calls to Docker Compose before (source code): file = self.files.get(thread_id) if not file: file = TemporaryFile(mode="w") os.set_inheritable(file.fileno(), True) yaml.dump(self.compose, file) self.files[thread_id] = file So yesterday I added a file.flush() after the yaml.dump and hoped to be done with it. This morning I woke up and the issue was still occurring! Based on the logged docker call this should be the code causing the problem (source code): def handle_composition( self, args: argparse.Namespace, composition: Composition ) -> None: if args.workflow not in composition.workflows: # Restart any dependencies whose definitions have changed. # This is Docker Compose's default behavior for `up`, but # not for `run`, which is a constant irritation that we # paper over here. The trick, taken from Buildkite's # Docker Compose plugin, is to run an `up` command that # requests zero instances of the requested service. if args.workflow: composition.invoke( "up", "-d", "--scale", f"{args.workflow}=0", args.workflow, ) super().handle_composition(args, composition) else: [...] Running the test in an endless loop locally had no success of reproducing the issue: while true; do bin/mzcom ## Ep. 11: Enhancing Go Code with Effective Application Layer Tests DevFeed: [Ep. 11: Enhancing Go Code with Effective Application Layer Tests]() Original publisher: [Read original article]() Published: 2024-07-30T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Testing](), [test-coverage](), [Software Engineering]() Tags: [code-coverage](), [comprehensive-go-testing](), [context](), [context-management-go-tests](), [continuous-integration](), [debugging-go-applications](), [effective-test-organization-go](), [efficient-go-testing-techniques](), [error-handling](), [go](), [go-application-layer-tests](), [go-authentication-tokens](), [go-continuous-integration-testing](), [go-dependencies-management](), [go-error-handling-consistency](), [go-middleware-handlers](), [go-project-test-implementation](), [go-subtests-domain-level](), [go-testing-strategies](), [maintaining-go-software-quality](), [mock-apis-go-testing](), [reliable-go-codebase](), [resilient-go-application](), [scalable-go-software-systems](), [table-driven-tests](), [table-driven-tests-go](), [testing](), [tests](), [unit-tests]() ### AI overview Episode 11 of the Ultimate Software Design series explains how to implement application-layer tests in Go. It covers domain-level test organization, subtests, table-driven tests, mock APIs, dependency management, authentication tokens, context, and consistent error handling, with the goal of broad coverage using minimal database instances. ### Source excerpt Introduction: Welcome to Episode 11 of our Ultimate Software Design series! In this episode, Bill delves into the intricacies of implementing robust application layer tests within Go projects, providing developers with essential strategies for creating scalable and maintainable software systems. Implement application layer tests that ensure comprehensive coverage with minimal database instances. Organize tests at the domain level using subtests for easier issue isolation and resilient code. Manage dependencies, authentication tokens, and context for smooth information flow and consistent error handling. ## Blacksmith builds faster CI analytics with Tinybird DevFeed: [Blacksmith builds faster CI analytics with Tinybird]() Original publisher: [Read original article]() Author: Tinybird Published: 2024-07-24T00:00:00Z Content type: article Language: en Sources: [Tinybird]() Topics: [ci](), [GitHub Actions](), [GitHub]() Tags: [analytics](), [ci](), [continuous-integration](), [customer-stories](), [github](), [github-actions]() ### AI overview The article describes Blacksmith's offering of GitHub Actions that are presented as twice as fast and less than half the cost, with user-facing CI analytics powered by Tinybird. ### Source excerpt Learn how a fast-moving startup is shaking up the world of Continuous Integration by offering 2x faster GitHub Actions at less than half the cost, with user-facing CI analytics powered by Tinybird. ## Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco DevFeed: [Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco]() Original publisher: [Read original article]() Published: 2024-07-24T00:00:00Z Content type: article Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [benchmarking](), [Testing](), [ci]() Tags: [benchmarking](), [container](), [continuous-integration](), [falco](), [gsoc](), [mentorship](), [midterm](), [testing](), [yaml]() ### AI overview A GSoC 2024 mentee describes progress improving Falco's event-generator for testing and benchmarking. The project includes declarative YAML-based Falco rule testing, a container runner, and planned CI pipelines to assess threat-detection correctness and performance. ### Source excerpt Hello Falco community, I'm Kiriti, a current GSoC mentee under Falco Security. I have been working diligently to improve the testing and benchmarking capabilities of Falco's event-generator project. Now that we've reached the midterm of GSoC, I'm eager to share the journey so far. In this blog, I'll delve into the details of my contributions, particularly focusing on two key PRs that have been merged, and outline my plans for the remainder of the program. My Project: Enhancing Falco's Event-Generator The event-generator is a vital utility within the Falco ecosystem, designed to test Falco's detection capabilities. My Google Summer of Code project focuses on upgrading the event-generator to enhance its testing and benchmarking capabilities, reliability, and consistency. Additionally, I am developing new Continuous Integration (CI) pipelines based on the upgraded event-generator. The ultimate goal is to evolve the event-generator into the standard tool for systematically assessing the correctness and performance of Falco's threat detection capabilities during every release and development cycle. My Journey So Far: Before being selected for GSoC, I contributed to the event-generator repository. I am grateful to Leonardo Grasso and Federico Di Pierro, who played a vital role in getting my PRs merged during the pre-GSoC contribution phase. These contributions helped me understand the event-generator codebase. I am also thankful to my mentors, Jason Dellaluce and Aldo Lacuku, for selecting me as a GSoC mentee. I will share my complete story of getting selected to GSoC in future. After my selection, Jason, Aldo, and I collectively designed a plan to enhance the event-generator. The community bonding period was crucial in designing and understanding the implementation plan. You can view our idea here, which we will implement during this GSoC period. Once the coding period began, we managed to merge two key PRs before the midterm. These PRs partially added support for testin [Next page]()