[katbyte]

A new rule, AZT006, that reports update tests applying a single config, or the same config more than once.

Why: an update test exists to run the resource's Update path. With one config it only proves the resource can be created, and with the same config twice the second apply is a no-op plan. The name says the update was tested when it never ran. A survey of azurerm found two such tests, the healthcare service identity update and the Security Center subscription pricing update, plus one scale set test that applies the same rolling-update config twice.

Update tests that never update. A test counts when a segment of its name after the first underscore starts with update, the same reading AZT005 uses, so _update, _updateSku and _list_update count and _autoUpdateEnabled does not. The configs are the Config values of the TestStep literals in the body, compared as written, so the same helper with different arguments is a different config. A test with no steps of its own delegates to a helper, and the helper is checked instead; lowercase testAcc helpers count, since sequential tests keep their steps there.

 	data.ResourceTest(t, r, []acceptance.TestStep{
+		{
+			Config: r.basic(data),
+		},
+		data.ImportStep(),
 		{
 			Config: r.complete(data),
 		},

Things that are fine as they are. Names where update is inside a word, such as imagesDisableAutomaticUpdate or AutoUpdates, are feature names and are not reported; a looser reading would have flagged four of those in azurerm. Delegating wrappers like the Cosmos DB account update tests, which hand off to a helper with the steps, are not reported either.

The rule only reports.