# Integration testing Integration testing is a software-testing approach that combines application components or modules and evaluates how well they work together. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to Migrate a Legacy Monolith Incrementally Without a Big-Bang Rewrite DevFeed: [How to Migrate a Legacy Monolith Incrementally Without a Big-Bang Rewrite]() Original publisher: [Read original article]() Author: Hugo Teijiz Published: 2026-09-17T23:27:03Z Content type: tutorial Language: en Sources: [freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More]() Topics: [Legacy Modernization](), [migration](), [Refactoring](), [Testing](), [Integration testing](), [observability](), [Routing (disambiguation)](), [Transactions](), [TypeScript](), [API](), [service](), [Dependency injection]() Tags: [artificial-intelligence](), [how-to](), [incremental](), [integration-testing](), [legacy](), [legacy-code](), [migrate](), [migration](), [monolith](), [refactoring](), [rewrite](), [routing](), [software-architecture](), [transactions]() ### AI overview A tutorial on migrating a legacy monolith incrementally by moving one business capability at a time. It covers characterization tests, boundaries between legacy and new code, parallel implementations, progressive traffic, observability, rollback paths, data ownership, and removing migrated behavior. ### Source excerpt Large legacy migrations often fail long before the final cutover. The failure usually starts when the migration is framed as a single event. Move the application. Move the database. Move all the users ## How to Use Differential Testing During a Legacy Migration DevFeed: [How to Use Differential Testing During a Legacy Migration]() Original publisher: [Read original article]() Author: Hugo Teijiz Published: 2026-09-14T16:25:50Z Content type: tutorial Language: en Sources: [freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More]() Topics: [migration](), [Testing](), [TypeScript](), [Integration testing](), [API](), [observability](), [Artificial Intelligence]() Tags: [ai](), [api](), [architecture](), [artificial-intelligence](), [code](), [how-to](), [integration](), [legacy-code](), [legacy-modernization](), [migration](), [modernization](), [observability](), [software-architecture](), [software-testing](), [testing](), [tests](), [tutorial](), [typescript]() ### AI overview This tutorial explains how to use differential testing during a legacy migration by running old and new implementations with identical inputs and comparing their behavior. It covers equivalence rules, output normalization, nondeterministic values, errors, side effects, automated testing, mismatch analysis, production shadow traffic, and using AI to classify divergences without allowing it to determine correctness. ### Source excerpt The most dangerous moment in a legacy migration isn't necessarily when you start writing the new implementation. It's when the new implementation looks finished. The code compiles, the tests pass, the ## Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase DevFeed: [Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase]() Original publisher: [Read original article]() Author: Lily Mara Published: 2026-09-10T09:34:00Z Content type: article Language: en Sources: [InfoQ]() Topics: [rust refactoring](), [Refactoring](), [Integration testing]() Tags: [architecture](), [cost](), [culture-methods](), [design](), [development](), [engineering](), [infoq](), [infrastructure](), [performance](), [presentation](), [python](), [qcon-san-francisco-2025](), [qcon-software-development-conference](), [refactoring](), [rust](), [rust-refactoring](), [system-programming](), [testing](), [transcripts]() ### AI overview A presentation on incrementally refactoring Python bottlenecks into Rust with PyO3 to improve function-level performance, retain integration testing, and reduce infrastructure costs. ### Source excerpt Lily Mara explains how to avoid high-risk software rewrites through incremental FFI refactoring. She shares how engineering teams can replace Python bottlenecks with Rust via PyO3, demonstrating how to achieve dramatic function-level speedups, seamless integration testing, and meaningful infrastructure cost savings without microservice overhead. By Lily Mara ## Introducing Consort: Test-driven development on a branching database DevFeed: [Introducing Consort: Test-driven development on a branching database]() Original publisher: [Read original article]() Author: Kevin Hartman Published: 2026-09-09T13:41:25Z Content type: article Language: en Sources: [Databricks]() Topics: [Test-driven development](), [Database](), [Integration testing](), [Software Engineering](), [Refactoring](), [Continuous Delivery (CD)](), [Pull Request](), [Reverse Engineering]() Tags: [code](), [continuous-delivery](), [database](), [development](), [integration](), [partners](), [platform](), [postgres](), [pull-request](), [refactoring](), [reverse-engineering](), [software](), [software-development](), [testing]() ### AI overview The article introduces Consort, a workflow for applying test-driven development to a branching database. It argues that copy-on-write branches of a real database can replace mocks, bring integration testing into the inner development loop, and let engineers run destructive tests in isolation. Versioned schema migrations can move with the dependent code, enabling what the article calls Data CD and helping catch production database problems during pull requests and merges. ### Source excerpt For 25 years I built software on the practices I grew up with: Kent Beck's TDD, Martin... ## What is the future of software engineering with Adam Bender, Principal Software Engineer at Google DevFeed: [What is the future of software engineering with Adam Bender, Principal Software Engineer at Google]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-07-02T15:01:06Z Content type: opinion Language: en Sources: [Tech World With Milan Newsletter]() Topics: [future of software](), [Software Engineering](), [AI-assisted coding](), [Testing](), [Integration testing](), [Google]() Tags: [ai](), [ai-coding](), [code-generation](), [conway-s-law](), [future-of-software](), [integration-testing](), [software-engineering]() ### AI overview The article discusses Adam Bender's view that the AI coding debate focuses too narrowly on speed. It argues that faster code generation increases pressure on testing, review, engineering culture, system understanding, and long-term maintainability, with integration testing becoming a particular challenge. ### Source excerpt Most of the AI coding debate is about speed. ## A new era for software testing DevFeed: [A new era for software testing]() Original publisher: [Read original article]() Published: 2026-06-07T09:46:06Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Testing](), [Software Testing](), [Integration testing](), [AI Agent](), [Large Language Model]() Tags: [ai-agent](), [integration-testing](), [llms](), [markdown](), [software-testing](), [testing]() ### AI overview The article argues that large language models can extend conventional software QA and testing by having an AI agent perform manual checks described in a Markdown file. It contrasts locally scoped tests, integration tests, and manual QA passes, and gives DwarfStar, an inference engine for open-weight LLMs, as an example. ### Source excerpt Automatic programming dramatically speeds up writing software in certain use cases and in the right hands. In my experience the output does not reach the structural quality and economy of complexity of the best hand-written software. However, not all the software is stellar, and my feeling is that automatic programming surpasses most of the times (and if well managed) the quality of decently developed hand-written code. Yet, there is a tradeoff between quality and time, in the case of writing new software with AI. This tradeoff in certain projects I developed can be brutal, that is, completing projects that may take many months in a few weeks. However, there are domains where LLMs simply open new strictly more powerful ways to automate processes, without any compromise on quality. One of those domains is software QA and testing. Traditionally software is tested using test suites that are composed of locally-scoped tests and integration tests (think of Redis: one thing is testing if SET foo 10 will be matched by GET foo => 10, another thing is testing if replication works in this case). And then by QA passes that are usually manually executed, and that can capture holes in the runnable test suite. It is a known fact that covering all the lines of the code does not mean covering all the possible states. Moreover integration testing is structurally hard: there are a number of timing issues, setups, and certain quality outputs that can only be visually inspected and not automatically checked that leave a lot of testing opportunities not really exploited because of time or logistic constraints. LLMs offer a new way to do QA on top of the existing testing methodologies. The idea is to create a markdown file where an AI agent is asked to work as a QA engineer, performing a number of manual testings on the new release. For instance, in the case of DwarfStar (an inference engine for open weights LLMs) I use the following approach. In the markdown file, the agent is asked to ## Simplex rethinks software development with Codex DevFeed: [Simplex rethinks software development with Codex]() Original publisher: [Read original article]() Published: 2026-05-07T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [Software](), [software-development](), [codex](), [ChatGPT](), [Artificial Intelligence](), [AI Development](), [code productivity](), [Generative AI](), [AI-assisted coding](), [Code generation](), [Integration testing](), [Command-line interface]() Tags: [ai](), [chatgpt](), [cli](), [code](), [code-generation](), [codex](), [coding](), [deployment](), [developers](), [development](), [generative-ai](), [integration](), [productivity](), [python](), [software-development]() ### AI overview Simplex uses ChatGPT Enterprise and Codex to improve software development productivity, reporting reduced time for design, development, and internal integration testing. ### Source excerpt Simplex boosts software development with ChatGPT Enterprise and Codex, reducing design, build, and testing time while scaling AI-driven workflows. ## BGP Labs: Graceful Degradation for Unsupported Devices DevFeed: [BGP Labs: Graceful Degradation for Unsupported Devices]() Original publisher: [Read original article]() Published: 2026-04-15T05:59:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [Network](), [Testing](), [Integration testing]() Tags: [bgp](), [devices](), [integration-testing](), [netlab](), [network](), [testing]() ### AI overview The article explains how netlab's online BGP labs handle unsupported device capabilities. A generic plugin adjusts lab topologies and validation tests based on available features, allowing affected labs to start with warnings and explanations instead of failing immediately. ### Source excerpt A few weeks ago, I described the changes in the online BGP labs that allow you to use most of the common network operating systems as "external" routers1. However, while we keep improving it, netlab still can't configure all BGP features on all supported devices (PRs from Nokia and Mikrotik fans would be highly appreciated 😎), which means that it's possible to configure your environment in a way where some of the more complex labs would simply fail to start. The limited choice of devices for external routers was always well-documented (example), but if you insisted on using unsupported devices, the lab would fail to start with an error message, and you'd have to tweak the lab topology (example). Wouldn't it be better to start the lab with a warning? Read more ... ## Hardware testing automation: a minimum viable product DevFeed: [Hardware testing automation: a minimum viable product]() Original publisher: [Read original article]() Published: 2026-01-21T00:00:00Z Content type: release Language: en Sources: [postmarketOS Blog]() Topics: [Automation](), [Testing](), [Integration testing](), [GitLab](), [ci](), [Tooling](), [qemu](), [Kernel](), [boot](), [Embedded Software Dev](), [deploy](), [x86]() Tags: [automation](), [boot](), [ci](), [firmware](), [gitlab](), [hardware](), [integration-testing](), [kernel](), [postmarketos](), [qemu](), [testing](), [x86]() ### AI overview The postmarketOS team reports a minimum viable hardware-testing automation system now integrated into its regular development workflow. It provides QEMU runners and a OnePlus 6T real-hardware runner in GitLab, supports integration testing on device runners, and describes related PCB revisions and control firmware. ### Source excerpt Since our last update in May we have continued working on hardware-testing automation. We are happy to announce that we have reached an important milestone: we are now testing the OnePlus 6T as part of our regular development workflow! If you are not sure why this is important, or want to read more about the design decisions and the different parts that compromise the system, you can find all the information in the previous blog post. Work done and current status Since May, the system that we designed has been put in place. To make it possible, the following work has been executed: 4 QEMU runners available, 2 for x86_64, 1 for aarch64, and 1 for armv7 are now available in GitLab, and can be used in any project. This can be done importing the corresponding tags. Thanks Oliver and Martin R. for setting these up! A OnePlus 6T runner is now also available in GitLab, which means that if selecting this device, tests will run on real hardware. You can see a full demo video of the device booting up in here. Thanks Martin R. and Clayton for setting it up! Thanks to Martin R. and Pablo, support for integration testing on the device-runners is now available in our GitLab (!17, !19, !20) and integrated in: postmarketos-mkinitfs (!63) boot-deploy (!81) pmaports (!6696, !7553, !7489) Thanks to Federico and Nicola, the PCB to control the hardware went through 3 revisions: The first revision (v0.1) included just 2 assembled boards, and other empty ones for debugging. The PCBs were received, and although non-functional, most issues could be debugged successfully. The second version (v0.2) included the fixes from the first revision, and consisted already of 5 fully assembled PCBs. This version is already good enough for being used to power the OnePlus 6T in Martin R.'s farm. The third revision (v0.3), has some small fixes, and potentially support for buttons for Samsung (and maybe other) devices. This order is a bigger batch of 20 boards to distribute to Trusted Contributors, and sho ## The best way to clean up test data with Spring and Hibernate DevFeed: [The best way to clean up test data with Spring and Hibernate]() Original publisher: [Read original article]() Author: vladmihalcea Published: 2025-11-11T08:05:24Z Content type: tutorial Language: en Sources: [Vlad Mihalcea]() Topics: [Spring Boot](), [Integration testing](), [Testing](), [Java](), [Spring Framework]() Tags: [cleanup](), [hibernate](), [integration-testing](), [java](), [jpa](), [schema](), [spring](), [spring-boot](), [test-data](), [testing](), [truncatemappedobjects]() ### AI overview This tutorial examines how to clean up test data in Spring and Hibernate integration tests. It argues that relying on @DataJpaTest for automatic transaction rollback is not always appropriate and discusses limitations of its SQL logging, including its inability to show bind parameter values or indicate whether batching is used. ### Source excerpt Introduction In this article, I'm going to show you the best way to clean up test data when using Spring and Hibernate. While it's very common to use the @DataJpaTest annotation when implementing integration tests, in this blog post, you will see why you are better off avoiding using this annotation. Why I don't use @DataJpaTest As explained by the manual, Spring Boot provides the @DataJpaTest annotation for Spring Data JPA integration testing. Once the @DataJpaTest annotation is added to an integration test, Spring Boot will make the following changes to the... Read More The post The best way to clean up test data with Spring and Hibernate appeared first on Vlad Mihalcea. ## SwiNOG 40: When a Routing Control Functions Is Too Fresh DevFeed: [SwiNOG 40: When a Routing Control Functions Is Too Fresh]() Original publisher: [Read original article]() Published: 2025-09-17T05:33:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Integration testing](), [bug](), [BGP](), [Routing Security](), [Network]() Tags: [bgp](), [bug](), [integration](), [integration-testing](), [routing](), [routing-security](), [rpki](), [video]() ### AI overview The article highlights a bug encountered during integration testing of network devices: applying a newly defined Routing Control Function to BGP routing updates in the same Arista EOS configuration session can produce unexpected behavior. The related SwiNOG 40 video presentation notes that the bug has since been fixed. ### Source excerpt During integration testing, I find unexpected quirks in network devices way too often. However, that's infinitely better than experiencing them in production (even after thoroughly testing stuff) while discovering that your peers don't care about routing security, RPKI, and similar useless stuff. For example, what happens if you define a new Routing Control Function (RFC) on Arista EOS and apply it to BGP routing updates in the same configuration session? You'll find out in the Sorry We Messed Up (video) presentation Stefan Funke had at SwiNOG 40 (note: the bug has been fixed in the meantime). ## Arista EOS Spooky Action at a Distance DevFeed: [Arista EOS Spooky Action at a Distance]() Original publisher: [Read original article]() Published: 2025-03-17T08:10:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Integration testing](), [Ethernet](), [qemu](), [Linux](), [JSON]() Tags: [blog](), [blog-post](), [ethernet](), [integration-testing](), [ipv4](), [json](), [lan](), [linux](), [netlab](), [qemu](), [testing](), [tests](), [validation](), [virtualization]() ### AI overview This blog post investigates unexpected Arista EOS behavior found during netlab VRRP integration testing. In a minimal lab, shutting down one switch interface caused the other switch's Ethernet line protocol to go down and stopped responses from the VRRP backup. Packet capture indicated that the first switch sent a packet instructing the peer to emulate remote link loss. ### Source excerpt This blog post describes yet another bizarre behavior discovered during the netlab integration testing. It started innocently enough: I was working on the VRRP integration test and wanted to use Arista EOS as the second (probe) device in the VRRP cluster because it produces nice JSON-formatted results that are easy to use in validation tests. Everything looked great until I ran the test on all platforms on which netlab configures VRRP, and all of them passed apart from Arista EOS (that was before we figured out how Sturgeon's Law applies to VRRPv3) - a "That's funny" moment that was directly responsible for me wasting a few hours chasing white rabbits down this trail. Read more ... ## How the Gremlin agent fails safely DevFeed: [How the Gremlin agent fails safely]() Original publisher: [Read original article]() Author: Andre Newman Published: 2025-01-30T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Chaos Engineering](), [experiments](), [Integration testing](), [Linux](), [Network]() Tags: [architecture](), [chaos-engineering](), [data-center](), [gremlin](), [integration](), [linux](), [network](), [server](), [testing]() ### AI overview The article explains how the Gremlin agent makes Chaos Engineering and reliability testing safer. Agents periodically check in with the Gremlin Control Plane and automatically stop active experiments and restore systems if communication is lost. ### Source excerpt Reliability testing shouldn't feel risky. Learn how Gremlin makes testing safer with fail-safe agents and automatic rollbacks. ## Configuring IP Addresses Won't Make You an Expert DevFeed: [Configuring IP Addresses Won't Make You an Expert]() Original publisher: [Read original article]() Published: 2025-01-09T05:39:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Networks](), [Learning](), [networking](), [Routing (disambiguation)](), [Integration testing](), [Containers]() Tags: [art](), [container](), [containers](), [integration-testing](), [mistakes](), [netlab](), [ospf](), [production](), [reuse](), [routing](), [testing]() ### AI overview This opinion argues that repeatedly configuring routine networking details in labs does not by itself build expertise. The author describes using netlab to automate familiar setup, reuse lab designs, create new topologies quickly, and focus on unfamiliar networking concepts, while noting that adapting existing topologies can still be useful for engineers who work on running networks. ### Source excerpt A friend of mine recently wrote a nice post explaining how netlab helped him set up a large network topology in a reasonably short timeframe. As expected, his post attracted a wide variety of comments, from "netlab is a gamechanger" (thank you 😎) to "I prefer traditional labs." Instead of writing a bunch of replies into a walled-garden ecosystem, I decided to address some of those concerns in a public place. Let's start with: Read more ... ## Updating to .NET 8, updating to IHostBuilder, and running Playwright Tests within NUnit headless or headed on any OS DevFeed: [Updating to .NET 8, updating to IHostBuilder, and running Playwright Tests within NUnit headless or headed on any OS]() Original publisher: [Read original article]() Author: Scott Hanselman Published: 2024-03-07T01:12:13Z Content type: tutorial Language: en Sources: [Scott Hanselman]() Topics: [Playwright](), [.NET](), [Testing](), [Browser Automation](), [Integration testing](), [ASP.NET](), [Selenium](), [GitHub Actions]() Tags: [asp-net](), [automation-testing](), [browser](), [ci-cd](), [debug](), [devops](), [dotnetcore](), [integration](), [linux](), [net](), [playwright](), [selenium](), [testing](), [tests](), [unit-testing](), [visual-studio](), [vs-code](), [web](), [windows]() ### AI overview A tutorial on updating a .NET application to .NET 8 and running Playwright browser tests through NUnit. It explains the transition from IWebHostBuilder to IHostBuilder and describes cross-platform, headless or headed testing across local systems, containers, and CI environments. ### Source excerpt I've been doing not just Unit Testing for my sites but full on Integration Testing and Browser Automation Testing as early as 2007 with Selenium. Lately, however, I've been using the faster and generally more compatible Playwright. It has one API and can test on Windows, Linux, Mac, locally, in a container (headless), in my CI/CD pipeline, on Azure DevOps, or in GitHub Actions. For me, it's that last moment of truth to make sure that the site runs completely from end to end. I can write those Playwright tests in something like TypeScript, and I could launch them with node, but I like running end unit tests and using that test runner and test harness as my jumping off point for my .NET applications. I'm used to right clicking and "run unit tests" or even better, right click and "debug unit tests" in Visual Studio or VS Code. This gets me the benefit of all of the assertions of a full unit testing framework, and all the benefits of using something like Playwright to automate my browser. In 2018 I was using WebApplicationFactory and some tricky hacks to basically spin up ASP.NET within .NET (at the time) Core 2.1 within the unit tests and then launching Selenium. This was kind of janky and would require to manually start a separate process and manage its life cycle. However, I kept on with this hack for a number of years basically trying to get the Kestrel Web Server to spin up inside of my unit tests. I've recently upgraded my main site and podcast site to .NET 8. Keep in mind that I've been moving my websites forward from early early versions of .NET to the most recent versions. The blog is happily running on Linux in a container on .NET 8, but its original code started in 2002 on .NET 1.1. Now that I'm on .NET 8, I scandalously discovered (as my unit tests stopped working) that the rest of the world had moved from IWebHostBuilder to IHostBuilder five version of .NET ago. Gulp. Say what you will, but the backward compatibility is impressive. As such my code for Progr ## How to Run NixOS Integration Tests for a Python Service with GitHub Actions DevFeed: [How to Run NixOS Integration Tests for a Python Service with GitHub Actions]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2024-03-01T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [GitHub Actions](), [Testing](), [Integration testing](), [Python](), [systemd]() Tags: [ci](), [github-actions](), [integration-testing](), [python](), [server](), [testing]() ### AI overview A beginner-focused tutorial that builds a minimal Python TCP echo server, packages it as a NixOS systemd service, tests it with the NixOS integration test driver, and runs the tests on GitHub Actions. ### Source excerpt Discover how to set up, test, and deploy an example application server using NixOS and GitHub Actions for seamless CI. Unlock powerful integration testing now! ## Introduction to the NixOS Integration Test Driver DevFeed: [Introduction to the NixOS Integration Test Driver]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2023-10-24T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [Integration testing](), [virtualization](), [qemu](), [Python]() Tags: [integration-test](), [python](), [qemu]() ### AI overview An introductory guide to the NixOS Integration Test Driver, covering declarative test configurations, virtual machines and networks, and Python-based test workflows. ### Source excerpt This guide explores how to efficiently run the blazingly fast NixOS integration tests, orchestrate multiple VMs, and leverage Python scripting. ## Testing libraries for the Decentralized Web DevFeed: [Testing libraries for the Decentralized Web]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2022-10-24T17:00:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [Testing](), [IPFS](), [Ethereum](), [Integration testing](), [ci](), [WebRTC](), [JavaScript](), [P2P](), [web applications]() Tags: [ci](), [data](), [database](), [decentralized-web](), [ethereum](), [hosting](), [integration-testing](), [javascript](), [testing](), [web-applications](), [webrtc]() ### AI overview This article introduces MockIPFS and Mockthereum, network interception libraries for IPFS and Ethereum. It explains how they support automated integration testing and CI workflows while also serving as foundations for network proxy tools for decentralized web applications. ### Source excerpt The world of decentralized web applications is an exciting place that has exploded in recent years, with technologies such as IPFS and Ethereum opening up possibilities for a peer-to-peer web - creating applications that live outside the traditional client/server model, where users to interact and control their own data directly. At the same time, it's still immature, and for software developers it lacks a lot of the affordances & ecosystem of the traditional HTTP-based web app world. There's far fewer tools and libraries for developers working in this space. I've been working on improving this over the last year (as one part of a project funded by EU Horizon's Next Generation Internet initiative), by building network interception libraries for both IPFS & Ethereum: MockIPFS & Mockthereum. These each act as both an immediately useful automated testing library, to support modern integration testing & CI workflows, and a base for building more general network proxy tools for web applications using either (or both) technologies. If that sounds cool and you just want to jump straight in and try these for yourself, you can get started at github.com/httptoolkit/mockipfs/ and github.com/httptoolkit/mockthereum/. On the other hand, if you want to hear what this can do in practice, and learn a little about how it works under the hood, read on: A new way to build web apps Decentralized web apps often use a mix of many different technologies, at various layers of the stack, such as: IPFS - for decentralized static content hosting & data storage Ethereum - for decentralized consistent global state, computation on that state, and financial transactions Filecoin/Storj - for paid decentralized long-term content storage WebRTC - for peer-to-peer raw data transfer, and video/audio connections Service workers - a JavaScript API allowing fully offline web apps Handshake (HNS)/Ethereum Name System (ENS) - to map domain names to web applications GunDB - a decentralized database for the ## Traits for testing in Kotlin DevFeed: [Traits for testing in Kotlin]() Original publisher: [Read original article]() Published: 2021-08-06T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Testing](), [Integration testing](), [backend-development](), [interface]() Tags: [backend-development](), [integration-testing](), [interface](), [kotlin](), [testing](), [workshop-learning-programming]() ### AI overview This tutorial explains how to use Kotlin traits for integration testing, especially in backend applications. It presents an interface-based technique that lets traits access fake objects defined by a base integration test class. ### Source excerpt A trick needed when using traits for testing in Kotlin. ## Integration Testing in Go: Part II - Set-up and Writing Tests DevFeed: [Integration Testing in Go: Part II - Set-up and Writing Tests]() Original publisher: [Read original article]() Published: 2019-10-03T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Integration testing](), [Testing](), [Go Language](), [Databases](), [SQL](), [bug]() Tags: [ardan-labs](), [blog](), [code](), [database](), [examples](), [go](), [go-programming](), [golang](), [integration](), [integration-testing](), [introduction](), [post](), [programming](), [repo](), [sql](), [testing](), [tests]() ### AI overview This second installment in a two-part series explains how to prepare external systems for integration tests in Go. It focuses on configuring and seeding a Postgres database, using Go data structures for seed data, and writing and running tests against the database. ### Source excerpt Prelude This post is the 2nd installment of a 2 part series about integration testing. You can read the first installment, which is about executing tests in a restricted environment using Docker. The example repository that this post draws it examples from can be found in the integration-tests-example repo. Introduction "More than the act of testing, the act of designing tests is one of the best bug preventers known." - Boris Beizer ## Basic Integration Testing with Serverless Framework DevFeed: [Basic Integration Testing with Serverless Framework]() Original publisher: [Read original article]() Author: Maciej Skierkowski Published: 2019-07-10T00:00:00Z Content type: tutorial Language: en Sources: [Serverless Blog]() Topics: [serverless framework](), [Integration testing]() Tags: [apis](), [aws](), [aws-lambda](), [cloud-computing](), [faas](), [function-as-a-service](), [infrastructure-as-code](), [integration](), [integration-testing](), [news](), [release](), [serverless](), [serverless-architecture](), [serverless-framework]() ### AI overview The latest Serverless Framework release makes it easier to perform integration testing for APIs built with the Serverless Framework. ### Source excerpt With the latest Serverless Framework release, we made it easier to test APIs built with the Serverless Framework. ## Integration Testing in Go: Part I - Executing Tests with Docker DevFeed: [Integration Testing in Go: Part I - Executing Tests with Docker]() Original publisher: [Read original article]() Published: 2019-03-18T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Integration testing](), [Go Language](), [Software Testing](), [Docker](), [Docker Compose](), [Databases](), [Messaging]() Tags: [ardan-labs](), [blog](), [compose](), [databases](), [docker](), [go](), [go-programming](), [golang](), [integration-testing](), [messaging](), [programming](), [testing]() ### AI overview A tutorial on integration testing in Go. It explains how to use Docker and Docker Compose to run Go tests alongside application dependencies such as databases and messaging systems in a restrictive environment without Go pre-installed. ### Source excerpt Introduction "Testing leads to failure, and failure leads to understanding." - Burt Rutan Burt Rutan is an aerospace engineer who designed Voyager, the first plane to fly around the world without stopping or refueling. Although Rutan was not a software engineer, his words speak volumes to the importance of testing, even testing software. Testing software in all forms is extremely important, whether it be unit, integration, system, or acceptance testing. However, depending on the project, one form of testing can be more valuable than the others. In other words, sometimes one form of testing can lead to better understanding about the health and integrity of the software than the other forms. ## Introducing Exemplar for Automated Samples Testing DevFeed: [Introducing Exemplar for Automated Samples Testing]() Original publisher: [Read original article]() Author: Eric Wendelin Published: 2018-10-09T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Testing](), [Documentation](), [Integration testing](), [Gradle](), [Command-line interface](), [Logging](), [cURL]() Tags: [command-line](), [curl](), [docs](), [documentation](), [github](), [gradle](), [integration-testing](), [logging](), [testing]() ### AI overview This article introduces Exemplar, a library for automated testing of documentation samples and integration-test examples. It supports sample discovery, output normalization, flexible verification, command-line execution, embedded samples in structured documents, and configuration through a JUnit test runner or APIs. Gradle uses it to verify examples in documentation and guides while reducing integration-test boilerplate. ### Source excerpt This post introduces a new library called Exemplar. The goal of Exemplar is to ensure that users get outputs that you expect them to see. It handles sample discovery, normalization (semantically equivalent results, perhaps from different environments), and flexible output verification. It invokes any command-line tool in the environment to be invoked. You can also invoke curl, for example, to verify service API responses. Gradle uses this library to verify examples in docs and guides, and remove boilerplate from integration tests. Exemplar can be configured using a JUnit test runner (recommended) or using its APIs. See examples below and in the Exemplar GitHub repo. Use cases for Exemplar It's important that documentation samples are accurate. Imagine the frustration, trying to learn something new and having the examples fail to work. We think Exemplar works best as a documentation checking mechanism. It is not meant to substitute other forms of integration testing however. Exemplar is unique because it allows discovery of samples embedded in structured documents, as well as OutputNormalizers (bundled and custom ones), conveniences for using sample projects in "more traditional" integration tests (via @UsesSample("path/to/sample")), and allows samples to be programmatically modified (for extra environment setup, perhaps) before execution (SampleModifier). Exemplar is focused on logging and exit code outputs, and verifying other side effects is cumbersome (checking created files may require extra commands). Furthermore, although Exemplar can be used for any tool, it only has APIs for JVM projects. Sample project testing primer The sample-discovery library in Exemplar will consider any directory containing a *.sample.conf file under the samples root as a sample project. A sample config file is written in HOCON and tells sample-check how to run the sample project. It can be simple: executable: echo args: "Hello World" ... or more complex, with multiple steps: commands: [ ## Building and Testing Resilient Ruby on Rails Applications DevFeed: [Building and Testing Resilient Ruby on Rails Applications]() Original publisher: [Read original article]() Author: Simon Eskildsen Published: 2015-01-29T19:16:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Rails](), [Ruby](), [Shopify](), [Integration testing](), [Latency](), [Network](), [API]() Tags: [api](), [browser](), [developers](), [development](), [http](), [infrastructure](), [integration](), [latency](), [network](), [ruby](), [shopify](), [testing]() ### AI overview This article explains how Shopify prepared its Ruby on Rails applications for peak holiday traffic by prioritizing resiliency. It describes mapping service dependencies, isolating optional dependencies, and testing behavior when external services are slow or unavailable. The article introduces Toxiproxy, a TCP proxy with an HTTP API for simulating network conditions in local development and integration tests. ### Source excerpt Black Friday and Cyber Monday are the biggest days of the year at Shopify with respect to every metric. As the Infrastructure team started preparing for the upcoming seasonal traffic in the late summer of 2014, we were confident that we could cope, and determined resiliency to be the top priority. A resilient system is one that functions with one or more components being unavailable or unacceptably slow. Applications quickly become intertwined with their external services if not carefully monitored, leading to minor dependencies becoming single points of failure. For example, the only part of Shopify that relies on the session store is user sign-in - if the session store is unavailable, customers can still purchase products as guests. Any other behaviour would be an unfortunate coupling of components. This post is an overview of the tools and techniques we used to make Shopify more resilient in preparation for the holiday season. [Next page]()