Asserting Bounds and Dimensions — Layout Math in Dp, Not Pixels

Layout assertions belong in dp, run with a half-dp tolerance, and most of the interesting checks (padding, gap, alignment) are subtractions between two getUnclippedBoundsInRoot() rectangles. This skill picks the right size/position assertion, explains clipped vs unclipped, and shows the canonical "compute padding from two rects" pattern lifted directly from material3/ButtonTest.kt.

When to use this skill

• The developer wants to verify a Button is 48 dp tall, a Spacer is 16 dp wide, an Icon is at position (24.dp, 12.dp).
• The developer asks how to assert the padding between two composables.
• The developer asks about minimum touch target sizes (ChipDefaults.MinHeight + 1.dp).
• The developer is comparing layout values in pixels and wants the dp-typed equivalent.
• The developer mentions assertWidthIsEqualTo, getUnclippedBoundsInRoot, DpRect, getAlignmentLinePosition, getFirstLinkBounds.

When NOT to use this skill

• The check is about state (enabled, on, selected) — see ./asserting-node-state-and-text/SKILL.md.
• The check is "is the node on screen at all" — assertIsDisplayed() is enough; bounds math adds friction without value.
• The composable's bounds depend on an animation in flight — pause the clock first; see ../../synchronization/testing-animations-deterministically/SKILL.md.
• The bounds are relative to a screenshot — use a screenshot test instead.