# integration test Published articles for integration test. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From HTTP MCP to stdio: Lessons Connecting an AI Agent to a Desktop IDE DevFeed: [From HTTP MCP to stdio: Lessons Connecting an AI Agent to a Desktop IDE]() Original publisher: [Read original article]() Author: Eugene Petrenko Published: 2026-05-20T00:00:00Z Content type: article Language: en Sources: [Eugene Petrenko]() Topics: [Model Context Protocol](), [IntelliJ IDEA](), [AI Agent](), [Command-line interface](), [Cross-origin resource sharing (CORS)]() Tags: [agentic-coding](), [ai-agent](), [ai-agents](), [ai-coding](), [architecture](), [claude](), [cli](), [codex](), [devrig](), [docker-image](), [eugene-petrenko](), [integration-test](), [intellij](), [jonnyzzz](), [kotlin](), [ktor](), [mcp](), [mcp-steroid](), [report](), [tag-41199d53f463]() ### AI overview This article explains why an HTTP MCP server embedded in a desktop IntelliJ application proved unreliable on real workstations. It describes moving to stdio with a CLI coordinator called devrig, and emphasizes integration tests for the MCP layer, including issues involving dynamic ports, startup ordering, multiple IDEs, and mismatched transport support. ### Source excerpt The obvious way to connect an AI Agent to a running IntelliJ is an HTTP MCP server inside the IDE. I built it, shipped it, and used it daily -- and it kept breaking on real workstations: dynamic ports, start-order lottery, multiple IDEs, and the agent-up/IDE-down dead end. Here is why I moved the whole thing to stdio and a CLI coordinator called devrig, and what the journey taught me. ## Faster and cheaper NixOS integration tests with containers DevFeed: [Faster and cheaper NixOS integration tests with containers]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2026-03-13T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Testing](), [Containers](), [Nix](), [qemu]() Tags: [containers](), [faster](), [integration-test](), [testing]() ### AI overview This article introduces a container backend for the NixOS integration test driver as an alternative to its QEMU-based tests. It explains that container tests can reduce startup time and memory use, lower infrastructure requirements, and simplify GPU passthrough in cases where full virtual-machine isolation is unnecessary. ### Source excerpt The new container support in the NixOS integration test driver allows for faster and lighter testing, let's see how it works! ## Run NixOS Integration Tests on macOS DevFeed: [Run NixOS Integration Tests on macOS]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2024-03-08T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [macOS](), [qemu](), [Python](), [Linux]() Tags: [how-to](), [integration-test](), [linux](), [macos](), [python](), [qemu]() ### AI overview This tutorial explains how to run NixOS integration tests on macOS. The setup uses normal NixOS virtual machines while qemu and the Python test driver run natively on macOS, with a Linux Builder and required Nix capability flags. ### Source excerpt NixOS integration now run on macOS! Learn how to set it up and run complex integration tests on your Mac today! ## 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. ## How to setup remote docker host DevFeed: [How to setup remote docker host]() Original publisher: [Read original article]() Published: 2022-09-26T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Docker](), [Image](), [docker images](), [Testcontainers](), [Amazon EC2](), [Amazon Web Services](), [Linux](), [TLS (Transport Layer Security)](), [x86]() Tags: [arm](), [aws](), [containers](), [docker](), [docker-images](), [ec2](), [how-to](), [integration-test](), [linux](), [remote](), [tls](), [x86]() ### AI overview This tutorial explains how to set up a remote Docker host for integration tests when required ARM images are unavailable. It uses a Linux x86_64 AWS EC2 machine, configures TLS access to the Docker daemon, and connects a local Docker client to the remote host. ### Source excerpt Not all docker images are available for ARM architecture (hopefully this will improve over time). Right now I'm working on a project where images for ARM are not available. Emulation works ok (but slow) most of the time. Lately, I stumbled upon an interesting performance/startup issue when running amd64-based containers using testcontainers in an integration test. Read more ## How to Integration Test Stored Procedures with jOOQ DevFeed: [How to Integration Test Stored Procedures with jOOQ]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-08-22T12:36:00Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [Testing](), [Database](), [Testcontainers](), [Java](), [PostgreSQL]() Tags: [code](), [code-generation](), [database](), [gradle](), [how-to](), [integration-test](), [integration-testing](), [java](), [jooq](), [jooq-in-use](), [junit](), [maven](), [stored-procedures](), [testcontainers](), [unit-test]() ### AI overview This tutorial explains how to integration-test database stored procedures and functions with Java, jOOQ, Testcontainers, and JUnit. It shows how to run PostgreSQL in Testcontainers, generate jOOQ classes for stored procedures, and reuse Java test infrastructure instead of manually binding to procedures through JDBC. ### Source excerpt When you write stored procedures and functions in your database, you want to ensure their correctness, just like with your Java code. In Java, this is done with unit tests, typically with JUnit. For example, if you have the following code in Java: Then, you might write a test like this: But how do we ... Continue reading How to Integration Test Stored Procedures with jOOQ -> ## Effective Kotlin Item 46: Avoid member extensions DevFeed: [Effective Kotlin Item 46: Avoid member extensions]() Original publisher: [Read original article]() Published: 2021-07-18T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [function](), [interface]() Tags: [dsls](), [extension-function](), [function](), [integration-test](), [interface](), [kotlin](), [visibility-modifier](), [workshop-learning-programming]() ### AI overview This article explains how Kotlin member extension functions work and why they are generally discouraged. It recommends controlling visibility with visibility modifiers and identifies DSL builders, scope-related functions, and some integration test patterns as appropriate exceptions. ### Source excerpt What member extensions are, how they are possible and why we should avoid using them. ## Integration Tests with Jest, Supertest, Knex, and Objection in TypeScript DevFeed: [Integration Tests with Jest, Supertest, Knex, and Objection in TypeScript]() Original publisher: [Read original article]() Author: hello@taniarascia.com Published: 2021-04-06T00:00:00Z Content type: tutorial Language: en Sources: [Tania Rascia]() Topics: [TypeScript](), [Jest](), [Testing](), [API](), [Object-relational mapping](), [Express](), [Databases](), [migration]() Tags: [api](), [database-migration](), [express](), [integration](), [integration-test](), [jest](), [node](), [orm](), [testing](), [tests](), [typescript]() ### AI overview This article presents an approach to integration testing for a TypeScript Node/Express API using Jest, Supertest, Knex, and Objection.js. It covers test setup and teardown, database creation, migrations, seeding, real API calls, and successful and error responses. ### Source excerpt Recently, I set up unit and integration tests for a Node API in TypeScript, and I couldn't find a lot of resources for setting up and... ## Test naming convention DevFeed: [Test naming convention]() Original publisher: [Read original article]() Published: 2019-03-14T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Automation](), [unit tests](), [Development](), [Code review]() Tags: [api](), [automated](), [automation](), [code-review](), [database](), [excel](), [ide](), [integration-test](), [tests](), [verify]() ### AI overview This tutorial explains how to use automated tests to enforce naming conventions for test groups. It distinguishes fast unit tests from integration tests involving I/O, databases, external APIs, reports, and Excel imports, and argues that convention checks can serve as both automated enforcement and living documentation. ### Source excerpt How to introduce automated checks that will guarantee that conventions are followed in an example of test naming convention. I'm going to focus on creating automated process that will verify if test names do match conventions. Automation will allow us to forget about the rule because the computer will ensure it's followed. Test that I'm going to introduce will be living documentation inside the project and ensure no one will miss nor forget about the way we group tests. Read more ## Managing db schema changes without downtime DevFeed: [Managing db schema changes without downtime]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2018-03-22T06:30:05Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [Database Migration](), [migration](), [Deployment](), [Rails](), [CI/CD]() Tags: [activerecord](), [commit](), [continuous-deployment](), [database](), [deployment](), [downtime](), [exceptions](), [integration-test](), [outage](), [schema]() ### AI overview This article explains how database schema changes can cause deployment outages, especially when older application instances remain active and ActiveRecord caches schema information. It describes Discourse's use of richer migration logging and deployment patterns to reduce these risks. ### Source excerpt At Discourse we have always been huge fans of continuous deployment. Every commit we make heads to our continuous integration test suite. If all the tests pass (ui, unit, integration, smoke) we automatically deploy the latest version of our code to https://meta.discourse.org. This pattern and practice we follow allows the thousands of self-installers out there to safely upgrade to the tests-passed version whenever they feel like it. Because we deploy so often we need to take extra care not to have any outages during deployments. One of the most common reasons for outages during application deployment is database schema changes. The problem with schema changes Our current deployment mechanism roughly goes as follows: Migrate database to new schema Bundle up application into a single docker image Push to registry Spin down old instance, pull new instance, spin up new instance (and repeat) If we ever create an incompatible database schema we risk breaking all the old application instances running older versions of our code. In practice, this can lead to tens of minutes of outage! In ActiveRecord the situation is particularly dire cause in production the database schema is cached and any changes in schema that drop or rename columns very quickly risk breaking every query to the affected model raising invalid schema exceptions. Over the years we have introduced various patterns to overcome this problem and enable us to deploy schema changes safely, minimizing outages. Tracking rich information about migrations ActiveRecord has a table called schema_migrations where it stores information about migrations that ran. Unfortunately the amount of data stored in this table is extremely limited, in fact it boils down to: connection.create_table(table_name, id: false) do |t| t.string :version, version_options end The table has a lonely column storing the "version" of migrations that ran. It does not store when the migration ran It does not store how long it took the migration to ## On behavior verifications DevFeed: [On behavior verifications]() Original publisher: [Read original article]() Published: 2017-09-06T00:00:00Z Content type: article Language: en Sources: [Paweł Chudzik]() Topics: [Refactoring](), [Mocking](), [Parsing](), [Smoke Tests]() Tags: [integration-test](), [mocking](), [refactoring](), [test](), [tests]() ### AI overview A developer recounts refactoring springmock after its double-definition parsing class accumulated responsibilities. The article explains the resulting test failures and recommends incremental refactoring, integration or smoke tests, and verifying behavior through tests. ### Source excerpt When I've got some free time I try to add new features to springmock. Lately, after adding some new stuff I realized that double definition parsing class has more than one responsibility (class parsing, naming, definition creation, etc). So I've decided it's time to refactor it and split responsibilities into dedicated classes. Once I did that and tests in the shared kernel started to pass I executed mvn verify just to be sure that everything was working and it wasn't... Read more ## Write that first complicated test DevFeed: [Write that first complicated test]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-03-01T05:05:56Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Testing](), [unit test](), [Pull Request](), [Git](), [networking](), [Concurrency](), [ui]() Tags: [also](), [code](), [git](), [integration-test](), [testing](), [tests](), [unit-test]() ### AI overview This article explains how to approach testing complicated code involving threads, commands, Git, networking, or user interfaces. It recommends investing in fakes, mocks, fixtures, and test-specific configuration, and using integration tests as a practical starting point when fast unit tests are difficult to write. ### Source excerpt What code of yours isn't tested? Is it code that deals with complicated situations that you don't control? Threads, running commands, git, networking, or UI? Our apps are most interesting when they're complicated. They're also most dangerous. And that's why code that's hard to test is exactly the kind of code that needs to be tested well. That doesn't always happen. Instead, every time you touch that code, you touch lightly. You tread carefully. Maybe you do some manual testing. And when you send the pull request, you hope your teammates don't realize those tests don't exist. But that won't make things better. You'll run into the same problems, the same bugs, the same stress next time - and every time after that. How can you finally make those challenging tests something you can rely on? Shift your mindset The most frustrating thing about these tests? It's going to take ten times as long to write it as it feels like it should. If you estimate the time the test saves you against the time you spend writing the test, it just doesn't seem worth it. But it's not just about this test. It's about all your future tests. Most of the best-tested code I've seen has a lot of support. It's not just the code in test/models. Extremely well-tested code has fakes, it has mocks, it has a good set of test fixtures, it has configuration options specifically for the tests. All that takes time to write and put together. But once you have it, it feels so good. You can come up with test after test, feeling comfortable about your code, and confident in quickly you can move after the investment you've made. You can rely on the work you've already done. So it's not just about preventing bugs in complicated code. It's also about making future code easier to test, piece by piece. Make it an integration test (for now) Sometimes, though, it's not about understanding the value - I get it. Instead, I just get stuck because I can't figure out how to write a small, fast, unit test. How do you know yo ## Screencast: Using Pretender to mock a server with Ember.js DevFeed: [Screencast: Using Pretender to mock a server with Ember.js]() Original publisher: [Read original article]() Published: 2014-08-26T00:00:00Z Content type: tutorial Language: en Sources: [Robin Ward]() Topics: [Ember](), [JavaScript](), [test](), [Library](), [GitHub]() Tags: [branch](), [ember](), [integration-test](), [javascript](), [js](), [library](), [login](), [mock]() ### AI overview A screencast demonstrates how to use Pretender, a JavaScript mock server library, in an Ember.js integration test. The source code for the login application is available on GitHub, with the finished version in the pretender branch. ### Source excerpt Recently I fell in love with Pretender, the mock server library in Javascript, so I decided to record a screencast showing how to use it in an Ember.js integration test: The source code for the login application is on github. The finished version is in the pretender branch. ## Creating an Integration test in Ember.js (Screencast) DevFeed: [Creating an Integration test in Ember.js (Screencast)]() Original publisher: [Read original article]() Published: 2014-06-27T00:00:00Z Content type: tutorial Language: en Sources: [Robin Ward]() Topics: [Ember](), [Integration testing](), [Testing](), [Command-line interface]() Tags: [boilerplate](), [ember](), [ember-cli](), [how-to](), [integration-test](), [integration-testing](), [js]() ### AI overview A screencast tutorial explains how to set up integration testing in an Ember.js application with ember-cli, including the boilerplate required at the top of integration test files. ### Source excerpt Once upon a time it used to be difficult to create integration tests in Ember.js. Fortunately, the framework has come a long way and it's now really easy to get integration testing working in your application. This screencast shows how to set it up with ember-cli: There is some boilerplate code required that you'll need at the top of your integration test files if you want to do it yourself. Here it is: ## Automocking containers are not just for mocks DevFeed: [Automocking containers are not just for mocks]() Original publisher: [Read original article]() Published: 2011-04-13T00:00:00Z Content type: opinion Language: en Sources: [Tim Kellogg]() Topics: [Testing](), [unit tests](), [IoC (Disambiguation)]() Tags: [component](), [implementation](), [integration-test](), [testing](), [unit-tests]() ### AI overview The article argues that automocking containers can support partially mocked integration tests, not only unit tests using mocks. It describes MoqContrib's approach of favoring the last registered component, allowing tests to start with production implementations and replace selected components with mocks, or override mocks with production implementations. ### Source excerpt In my last post I introduced MoqContrib's automocking container. In this post I want to describe what sets it apart from MoqContrib's previous automocking container and all other automocking containers that I've heard of thus far.A Castle.Windsor contributor said that for unit tests, "it's recommended that you don't use the container at all, or if the test setup gets too dense because of dependencies, use an AutoMockingContainer." This is in response to a stack overflow question regarding how to remove components in order to replace them with mocks. There are others that agree with him.I don't agree with Mauricio or Derek (from the links above). I strongly believe that there are several reasons to let an automocking container have real services registered that aren't mocks. The primary reason is for integration tests. This is where you are testing a system of modules, a subset of the entire system, but you still need to isolate those modules to just the system under test (SUT). So while the dependencies within the SUT are going to be implemented with real implementations, everything else is mocked. This is a partially mocked situation.One of the big reasons to use an automocking container is just to simplify everything. Sure, you're setups are starting to get pretty long for unit tests, but sometimes you run into issues where there is already a component registered so you can't register a mock without first removing the original component. This is very tedious and totally ruins any love you might have had for your IoC container.In MoqContrib 1.0 the container will favor the last component registered over everything else. This is handy because you can do setups by exception. For an integration test fixture you can setup everything as a production implementation and then just mock components as needed. You can also do it the other way and just override with production implementations. I believe this will lead to much cleaner tests and much less time tracking down "how