# CfgMgmtCamp 2026 discussion (9/12): Deprecations and ansible-test

**URL:** <https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-9-12-deprecations-and-ansible-test/45296>\
**Category:** Collection Development\
**Tags:** cfgmgmgtcamp, ansible-test, deprecation\
**Created:** [February 7, 2026, 9:02pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-9-12-deprecations-and-ansible-test/45296 "2026-02-07T21:02:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [February 7, 2026, 9:02pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-9-12-deprecations-and-ansible-test/45296/1 "2026-02-07T21:02:01Z")

</div>

# As a collection developer/maintainer

**Deprecations and ansible-test**

# Latest developments

It seems that with better warning/deprecation control there might be improvements coming here as well.  
Right now it’s too early to tell.

# Original text

Right now, `ansible-test integration` swallows **all** deprecation messages.

If ansible-core deprecates something, looking at new deprecation warnings in integration tests **should** help finding this out. Unfortunately there’s no information on deprecations there.

The result is that maintainers don’t notice deprecations unless they happen to use the modules/plugins outside tests. Especially for collections such as community.general, where many things aren’t actively maintained, the result is that either eventually a user creates an issue about a deprecation, or (worse) eventually something suddenly and unexpectedly breaks since a deprecated feature was finally removed.

This makes it a bad developer experience, and often also a bad user experience as users see these deprecation messages that are aimed at developers. Deprecation messages you cannot really do something about are very frustrating.

It would be much better if deprecation warnings would not be eaten, but reported. It would be **even** better if you could explicitly say for a task which (deprecation) warnings are OK, and which ones should result in a failure. This requires being able to identify (deprecation) warnings though - see [“Speaking about deprecations”](https://forum.ansible.com/t/45291).

---

<div class="post-metadata">

**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\
**Post date:** [February 9, 2026, 6:12pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-9-12-deprecations-and-ansible-test/45296/2 "2026-02-09T18:12:49Z")

</div>

Surfacing deprecations and probably even warnings through ansible-test is something we’ve been talking about for a while. It helps the core team as well, since there are thousands of tasks in integration tests it’s often hard for us to find them as well. I don’t know what it would look like or any timeframe, but I’m generally in agreement with the sentiment of this.