# Mocking A software testing technique that replaces real dependencies with simulated components, or test doubles, to isolate and evaluate parts of an application. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Starting Android at Khan Academy DevFeed: [Starting Android at Khan Academy]() Original publisher: [Read original article]() Author: Khan Academy Published: 2016-02-29T23:00:00Z Content type: article Language: en Sources: [Khan Academy]() Topics: [Android](), [android-development](), [Development](), [Library](), [modules](), [ci](), [Mocking]() Tags: [android](), [android-development](), [development](), [engineering](), [libraries](), [mobile](), [mocking](), [module](), [modules](), [news](), [open-source](), [picasso](), [play-store](), [pre-commit](), [retrofit](), [test](), [tests]() ### AI overview Khan Academy describes its first Android app, launched in August 2015, and the engineering practices used to build it. The team adopted established Android and open-source libraries, separated Android-independent core code from the app module, and used fast JVM tests and continuous integration. ### Source excerpt By Ben Komalo The journey of a thousand miles... In March, 2015--almost 1 year ago to the day--we ... Read more ## API Mocking and Testing With Microcks DevFeed: [API Mocking and Testing With Microcks]() Original publisher: [Read original article]() Author: Andrei Branza Published: 2026-08-22T23:20:24Z Content type: tutorial Language: en Sources: [Baeldung]() Topics: [Mocking](), [Testcontainers](), [API](), [OpenAPI Specification](), [Microservices](), [Docker Compose](), [Docker](), [Kafka](), [Amazon Simple Queue Service (SQS)](), [GraphQL](), [gRPC](), [Jenkins]() Tags: [api](), [compose](), [docker](), [how-to](), [kafka](), [kubernetes](), [mocking](), [openapi](), [popular](), [testcontainers](), [testing](), [testing-popular-testcontainers]() ### AI overview This tutorial explains how to use Microcks with Testcontainers to generate API mocks from contracts and run conformance tests against real implementations. It covers importing an OpenAPI contract, starting Microcks in a JUnit 5 test, calling generated mock endpoints, and integrating mocking and testing into delivery workflows. ### Source excerpt Learn how to use Testcontainers integration to spin up Microcks inside a JUnit5 test. The post API Mocking and Testing With Microcks first appeared on Baeldung. ## How AI-Assisted Development Uses Reviewed Design Documents and Extensive Testing DevFeed: [How AI-Assisted Development Uses Reviewed Design Documents and Extensive Testing]() Original publisher: [Read original article]() Author: Brian Jenney Published: 2026-05-30T17:42:50Z Content type: article Language: en Sources: [Brian Jenney]() Topics: [Artificial Intelligence](), [Code](), [Testing](), [Documentation](), [Kubernetes](), [Terraform](), [Mocking](), [Boilerplate](), [GitHub API](), [Figma]() Tags: [ai](), [api](), [boilerplate](), [code](), [documentation](), [figma](), [github](), [kubernetes](), [mocking](), [terraform](), [testing]() ### AI overview The author describes an AI-assisted development workflow in which reviewed, versioned design documents provide context for coding agents. Agents handle implementation and testing boilerplate, while developers decide expected behavior and test coverage. The author connects this process with frequent deployments and confidence in changes. ### Source excerpt AI writes basically all of my code now. ## How to use Jest mocks DevFeed: [How to use Jest mocks]() Original publisher: [Read original article]() Author: Dan Lew Published: 2026-05-28T13:10:16Z Content type: tutorial Language: en Sources: [Dan Lew Blog]() Topics: [Jest](), [Mocking](), [JavaScript](), [Dependency injection]() Tags: [dependency-injection](), [how-to](), [javascript](), [jest](), [mocking](), [testing]() ### AI overview A practical introduction to Jest mocks covering module mocking, mock hoisting, automock behavior, and configuring mocked return values. It also notes limitations in the documentation and discusses considerations for TypeScript users. ### Source excerpt For better or worse, my life has become infested by Jest mocks. I come from the land of dependency injection (I even gave a talk once!), but whenever I talk about dependency injection to JavaScript developers I get this reaction: Instead, mocking is king. Unfortunately, I've found Jests& ## Practicing Playwright: API Testing, Intercepting Network Requests, and Mocking APIs DevFeed: [Practicing Playwright: API Testing, Intercepting Network Requests, and Mocking APIs]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-05-28T02:20:30Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [Testing](), [API](), [Mocking](), [Network]() Tags: [api](), [api-testing](), [browser](), [guide](), [mocking](), [network](), [playwright](), [testing]() ### AI overview A practical tutorial on Playwright API testing using page.route to intercept, modify, abort, fetch, and mock network requests. It examines tests for the PracticeSoftwareTesting.com shopping cart and shows how API data can support UI assertions. ### Source excerpt How would you intercept a network request and use the data for assertions? Mock a network request using those assertions? And make sure that all data is loaded in the UI before making your assertions, and that all tests can pass when run? We will be walking through Butch Mayhew's code that answers all of these questions, part of his LinkedIn Learning course: Playwright Essential Training. We will be examining the shopping cart test site PracticeSoftwareTesting.com and looking at code on Butch's companion GitHub site on how to mock out the API and use them in the UI tests. Playwright has a lot of features when it comes to API testing. You can intercept network requests, aborting, modifying, and mocking network requests. You can also simulate a slow network. This is all done through the Playwright methods: page.route. A route is the specific path or URL a client uses to request data or trigger a function on a server. GET /product would be an API call that gets everything from the address string called products, which then retrieves all products from the API endpoint called "products". The endpoint is "products" and the route is the name that accesses the endpoint. The Playwright API has a method called route, which allows Playwright to monitor and modify browser network traffic. Playwright.dev / Docs / Network: https://playwright.dev/docs/network Playwright and page.route: https://playwright.dev/docs/api/class-route Playwright Mocking API Guide: https://playwright.dev/docs/mock Adding page.route to your test allows you to do things such as: abort the route request with route.abort(), simulating various error codes such as accessdenied, addressunreachable, blockedbyclient, blockedbyresponse, connection aborted, connectionclosed, timedout, etc. continue sending the route's request with optional overrides such as changing the request URL, the headers, the method such as GET or POST, and the post data of the request. fetch the request without yet fulfilling it, so the res ## Lessons from Software Engineering at Google for Maintaining Healthy Codebases DevFeed: [Lessons from Software Engineering at Google for Maintaining Healthy Codebases]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-02-26T16:01:23Z Content type: opinion Language: en Sources: [Tech World With Milan Newsletter]() Topics: [Software Engineering](), [Development](), [Dependency management](), [Code review](), [Refactoring](), [engineering-culture](), [Mocking](), [releases](), [upgrade]() Tags: [code-review](), [dependency-management](), [engineering](), [leadership](), [mocking](), [release](), [software-engineering]() ### AI overview A review of Software Engineering at Google argues that the book's lessons apply to teams of different sizes. It highlights practices for evolving, sharing, testing, releasing, and eventually deleting code, along with code review, dependency management, productivity measurement, and engineering culture. ### Source excerpt And what you can apply from today. ## Stop Mocking Auth (It's Breaking Your Tests) DevFeed: [Stop Mocking Auth (It's Breaking Your Tests)]() Original publisher: [Read original article]() Author: Shridhar Deshmukh Published: 2025-12-29T18:23:12Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Mocking](), [Authentication](), [passwords](), [Databases]() Tags: [authentication](), [database](), [databases](), [mocking](), [password](), [product](), [testing]() ### AI overview The article argues that mocking authentication makes test suites misleading because mocks can bypass password verification, session management, database constraints, and relationships between authentication and application data. It recommends testing the behavior that can fail in production rather than only verifying mocked assumptions. ### Source excerpt If your application has user accounts, authentication touches everything: who can access what, what data belongs to whom, and how your system behaves when sessions expire or credentials are invalid. Auth is also one of the most commonly mocked components in test suites. The reaso... ## A Reproducible Process for Fixing Bugs DevFeed: [A Reproducible Process for Fixing Bugs]() Original publisher: [Read original article]() Published: 2025-10-21T00:00:00Z Content type: tutorial Language: en Sources: [Dan Abramov]() Topics: [bug](), [React Router](), [React](), [Claude](), [Mocking](), [browser]() Tags: [bug](), [claude](), [how-to](), [mocking](), [react](), [react-router]() ### AI overview The article describes debugging a web app where adding a React Router server call caused scrolling to jitter. It argues that reliable reproductions are essential because Claude and human engineers can propose incorrect fixes without a reproducible test. ### Source excerpt The joys of vibecoding. ## Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development DevFeed: [Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-21T08:05:36Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Test-driven development](), [Testing]() Tags: [mocking](), [tdd](), [testing](), [tests](), [video]() ### AI overview A recording from Denis Čahuk's live video explains the differences between mocks, stubs, fakes, and shunts, and examines how overusing or misunderstanding test doubles can create tangled tests. It discusses testing outgoing commands with mocks and how difficult mocking setups may indicate design problems. ### Source excerpt A recording from Denis Čahuk's live video ## How Mocking Affects Software Design and Testability DevFeed: [How Mocking Affects Software Design and Testability]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-19T07:45:14Z Content type: tutorial Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Testing](), [Test-driven development](), [Refactoring](), [test-coverage]() Tags: [coverage](), [mocking](), [mongodb](), [refactoring](), [tdd](), [testing]() ### AI overview A recorded talk examines when mocks are useful, common misconceptions about mocking and TDD, and how excessive or poorly chosen mocks can constrain software design and testability. It discusses multi-mock tests, database mocking, and designing narrow seams around dependencies. ### Source excerpt If you've ever felt like your tests get in the way of refactoring, or like mocks make everything harder rather than simpler this stream is for you. ## Node.js 24.3.0 (Current) DevFeed: [Node.js 24.3.0 (Current)]() Original publisher: [Read original article]() Published: 2025-06-24T23:05:50Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [Mocking]() Tags: [api](), [mocking](), [node-js](), [update]() ### AI overview Node.js 24.3.0 is a current release with filesystem event handling, type-stripping, test-runner mocking, and URL API changes, alongside dependency updates and fixes. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## Mocking Frameworks May Mask Design Problems DevFeed: [Mocking Frameworks May Mask Design Problems]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-06-12T12:54:42Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Frameworks]() Tags: [frameworks](), [mocking]() ### AI overview This commentary argues that teams may use mocking frameworks to save time while overlooking underlying design problems. It presents mocking as a temporary workaround that can conceal poor design decisions. ### Source excerpt Engineers glamorously flock to using mocking frameworks as a solution to saving time. In reality it is a band-aid provided by framework authors, baiting teams to ignore their subpar design decisions. ## How To Refactor Legacy Code DevFeed: [How To Refactor Legacy Code]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-04-12T05:01:26Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [Refactoring](), [Testing](), [Dependency injection](), [Test coverage](), [Mocking]() Tags: [dependency-injection](), [how-to](), [legacy-code](), [refactor](), [refactoring](), [testing](), [tests]() ### AI overview A six-step strategy for refactoring legacy code by breaking dependencies, using characterization and other testing techniques, achieving test coverage, and then changing the code. ### Source excerpt The art of making your code testable, testing it effectively, and refactoring it like a pro ## TDD February 2025 Agenda DevFeed: [TDD February 2025 Agenda]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-02-03T15:48:33Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Mocking](), [Development]() Tags: [2025](), [mocking](), [nextjs](), [tdd](), [testing]() ### AI overview A February 2025 agenda for TDD-related events, including talks on self-testing code, a new TDD booklet release, reaction streams, live chats, and a session on test-driven development with Next.js. ### Source excerpt What you can expect and goodies! ## Test Your Database Without Mocks DevFeed: [Test Your Database Without Mocks]() Original publisher: [Read original article]() Author: Andrew Tate Published: 2025-01-15T10:38:35Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Mocking]() Tags: [database](), [mocking](), [postgres](), [product](), [sql](), [testing](), [transactions]() ### AI overview The article argues that database mocks are brittle, costly to maintain, and unable to faithfully verify important database behavior. ### Source excerpt Mocks for databases are extremely brittle and complicated. - javcasas Mocks in general are rarely worth it, the DB ones: 10x so. - pdimitar Was dealing with mocking voodoo garbage this morning as a result of fixing a bug. What a horrible mess just to claim a few lines of "test co... ## Learning Path: Testing and Continuous Integration DevFeed: [Learning Path: Testing and Continuous Integration]() Original publisher: [Read original article]() Author: Real Python Published: 2024-11-14T12:00:00Z Content type: tutorial Language: en Sources: [Real Python]() Topics: [Python](), [Software Testing](), [CI/CD](), [GitHub Actions](), [Unit testing](), [Code quality](), [Docker](), [Mocking](), [Test-driven development]() Tags: [ci-cd](), [code-quality](), [docker](), [github-actions](), [learning](), [mocking](), [pytest](), [python](), [testing](), [tutorial]() ### AI overview A learning path for testing Python applications, covering unittest, doctest, mock objects, pytest, code quality, and continuous integration with GitHub Actions and Docker. ### Source excerpt Learn how to test Python code with unittest, doctest, pytest, and mock objects. Set up continuous integration with GitHub Actions and Docker. ## Node.js 23.1.0 (Current) DevFeed: [Node.js 23.1.0 (Current)]() Original publisher: [Read original article]() Published: 2024-10-24T21:32:29Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [JavaScript](), [Mocking](), [Command-line interface]() Tags: [benchmark](), [command-line](), [cross-platform](), [crypto](), [developers](), [github](), [javascript](), [node-js](), [open-source](), [sqlite](), [testing]() ### AI overview Node.js 23.1.0 is a current release that adds improvements including correct length updates for resizable ArrayBuffer-backed objects and stable support for MockTimers. The release also includes updates to networking, assertions, benchmarking, builds, cryptography, dependencies, and SQLite compilation. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## SMURF: Beyond the Test Pyramid DevFeed: [SMURF: Beyond the Test Pyramid]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-10-15T12:22:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [Mocking]() Tags: [adam-bender](), [article](), [dependency](), [flaky](), [google](), [integration](), [maintainability](), [memory](), [production](), [resources](), [speed](), [testing](), [tests](), [tott](), [unit-tests]() ### AI overview This Google Testing on the Toilet article explains why the conventional test pyramid is insufficient for growing test suites. It introduces the SMURF mnemonic--Speed, Maintainability, Utilization, Reliability, and Fidelity--as a framework for balancing testing trade-offs. ### Source excerpt This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Adam Bender The test pyramid is the canonical heuristic for guiding test suite evolution. It conveys a simple message - prefer more unit tests than integration tests, and prefer more integration tests than end-to-end tests. While useful, the test pyramid lacks the details you need as your test suite grows and you face challenging trade-offs. To scale your test suite, go beyond the test pyramid. The SMURF mnemonic is an easy way to remember the tradeoffs to consider when balancing your test suite: Speed: Unit tests are faster than other test types and can be run more often--you'll catch problems sooner. Maintainability: The aggregated cost of debugging and maintaining tests (of all types) adds up quickly. A larger system under test has more code, and thus greater exposure to dependency churn and requirement drift which, in turn, creates more maintenance work. Utilization: Tests that use fewer resources (memory, disk, CPU) cost less to run. A good test suite optimizes resource utilization so that it does not grow super-linearly with the number of tests. Unit tests usually have better utilization characteristics, often because they use test doubles or only involve limited parts of a system. Reliability: Reliable tests only fail when an actual problem has been discovered. Sorting through flaky tests for problems wastes developer time and costs resources in rerunning the tests. As the size of a system and its corresponding tests grow, non-determinism (and thus, flakiness) creeps in, and your test suite is more likely to become unreliable. Fidelity: High-fidelity tests come closer to approximating real operating conditions (e.g., real databases or traffic loads) and better predict the behavior of our production systems. Integration and end-to-end tests can better reflect realistic conditions, while unit ## Node.js 22.3.0 (Current) DevFeed: [Node.js 22.3.0 (Current)]() Original publisher: [Read original article]() Published: 2024-06-11T19:00:57Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [JavaScript](), [Command-line interface](), [Mocking](), [Processes](), [tracing](), [Benchmark](), [Android](), [Python]() Tags: [android](), [benchmark](), [command-line](), [cross-platform](), [javascript](), [mocking](), [node-js](), [open-source](), [process](), [python](), [tracing]() ### AI overview Node.js 22.3.0 is a current release with semver-minor additions across the runtime, including WASI permission controls, Blob byte access, CommonJS load-time reporting, snapshot testing, module mocking, EventSource support, tracing for net.Server.listen, and process.getBuiltinModule(). It also stabilizes recursive copy methods and includes build and platform updates. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## Increase Test Fidelity By Avoiding Mocks DevFeed: [Increase Test Fidelity By Avoiding Mocks]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-02-27T18:43:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [Mocking](), [Software Engineering](), [Database](), [API]() Tags: [andrew-trenk](), [article](), [bugs](), [code](), [database](), [dillon-bly](), [in-memory-database](), [software](), [software-engineering](), [testing](), [tests](), [tott](), [unit-tests]() ### AI overview This Google Testing on the Toilet article explains that test fidelity is higher when tests use the real dependency implementation. If that is impractical, it recommends using a fake, such as an in-memory database, and using a mock only when neither a real implementation nor a fake is suitable. Mocks can reduce fidelity because their inline behavior may diverge from the real dependency. ### Source excerpt This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Andrew Trenk and Dillon Bly Replacing your code's dependencies with mocks can make unit tests easier to write and faster to run. However, among other problems, using mocks can lead to tests that are less effective at catching bugs. The fidelity of a test refers to how closely the behavior of the test resembles the behavior of the production code. A test with higher fidelity gives you higher confidence that your code will work properly. When specifying a dependency to use in a test, prefer the highest-fidelity option. Learn more in the Test Doubles chapter of the Software Engineering at Google book. Try to use the real implementation. This provides the most fidelity, because the code in the implementation will be executed in the test. There may be tradeoffs when using a real implementation: they can be slow, non-deterministic, or difficult to instantiate (e.g., it connects to an external server). Use your judgment to decide if a real implementation is the right choice. Use a fake if you can't use the real implementation. A fake is a lightweight implementation of an API that behaves similarly to the real implementation, e.g., an in-memory database. A fake ensures a test has high fidelity, but takes effort to write and maintain; e.g., it needs its own tests to ensure that it conforms to the behavior of the real implementation. Typically, the owner of the real implementation creates and maintains the fake. Use a mock if you can't use the real implementation or a fake. A mock reduces fidelity, since it doesn't execute any of the actual implementation of a dependency; its behavior is specified inline in a test (a technique known as stubbing), so it may diverge from the behavior of the real implementation. Mocks provide a basic level of confidence that your code works properly, and can be especially use ## .NET developers alert: Moq NuGET package exfiltrates user emails from git DevFeed: [.NET developers alert: Moq NuGET package exfiltrates user emails from git]() Original publisher: [Read original article]() Author: Liran Tal Published: 2023-08-09T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [.NET](), [NuGet](), [supply-chain-security](), [Testing](), [Mocking](), [Vulnerabilities](), [pii](), [Security](), [HTTP](), [Git](), [Azure](), [GitHub]() Tags: [acquisition](), [application-security](), [blog](), [capture](), [developer](), [devrel](), [dot-net](), [git](), [mocking](), [net](), [nuget](), [open-source-security](), [pii](), [security](), [snyk](), [snyk-open-source](), [supply-chain-security](), [testing](), [vulnerabilities]() ### AI overview The article reports that Moq, a widely used .NET mocking library, began exfiltrating developers' configured Git email addresses starting with version 4.20.0. The data was hashed into an HTTP request to Azure blob storage and shared with a third-party SponsorLink service. Snyk frames the incident as an open-source software supply-chain security and package-health concern. ### Source excerpt On August 8th 2023, the .NET community was made aware that the testing library called Moq exfiltrates developers emails from their development machine, and sends them off to third-party remote servers. ## Guide to Maestro UI Testing with API Mocking Using WireMock DevFeed: [Guide to Maestro UI Testing with API Mocking Using WireMock]() Original publisher: [Read original article]() Author: Ashish Kharche Published: 2023-06-19T07:00:00Z Content type: tutorial Language: en Sources: [mobile.dev - Medium]() Topics: [Mocking](), [Testing](), [ui](), [API](), [Command-line interface](), [HTTP](), [Cloud]() Tags: [api](), [backend](), [cli](), [cloud](), [code](), [guide](), [how-to](), [http](), [mock-api](), [mocking](), [testing](), [ui](), [ui-testing]() ### AI overview This step-by-step guide explains how to optimize Maestro UI testing by using mock APIs with WireMock. It covers local WireMock setup and WireMock Cloud's web UI, including response stubbing, request verification, proxying, record/playback, and fault injection. ### Source excerpt Mock with WireMock, UI test with Maestro ## Interfaces 101 : Testing with a Mock Interface Ep. 8 DevFeed: [Interfaces 101 : Testing with a Mock Interface Ep. 8]() Original publisher: [Read original article]() Published: 2023-03-20T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [interfaces](), [Go Language](), [Unit testing](), [Mocking](), [HTTP](), [client]() Tags: [api](), [go](), [golang](), [health-check](), [http](), [http-roundtripper](), [interfaces](), [mock-api](), [tests](), [unit-test](), [unit-testing](), [video]() ### AI overview This video tutorial explains how to design small, composable interfaces in Go and test an API client. It demonstrates performing HTTP requests and using a mock implementation to specify server response codes during unit testing. ### Source excerpt Introduction In episode 7, Miki discussed design considerations to keep in mind while creating interfaces in Go with the first idea he proposed being that an interface should represent what we need from a type, and not what is stored on the type. To add some clarity to this thought, Miki explained how the io.Reader and io.Writer interfaces each require one method to be implemented although the underlying concrete type may store more information. The second idea he proposed was that interfaces should be small, with less than 6 methods, to ensure your code remains composable. ## Interfaces 101 : Implementing Generics with Interfaces Ep. 1 DevFeed: [Interfaces 101 : Implementing Generics with Interfaces Ep. 1]() Original publisher: [Read original article]() Published: 2023-01-31T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [interfaces](), [Go Language](), [Mocking]() Tags: [code](), [developers](), [generic-programming](), [generics](), [go](), [go-types](), [golang](), [interfaces](), [mocking](), [polymorphism](), [series](), [types](), [video]() ### AI overview A video tutorial explains how Go interfaces can constrain the types accepted by generic functions. It covers defining generic functions, explicitly passing types, and addressing compiler recognition issues while replacing duplicate functions that return different types. ### Source excerpt Introduction Go interfaces are beneficial to Go developers because they: Allow interfaces to separate mechanism from behavior. Increase flexibility of function parameters. Enable mocking of function parameters. With the addition of generics in Go 1.18, interfaces can be used to constrain the types of values a generic function will accept. To dive deeper into Go interfaces, we invite you to join Miki in his latest series dedicated to Go interfaces. [Next page]()