Improve tests in internal/states (ProviderAddrs, HasCurrent, Unlock)

[davidspielmann]

Fixes #37649

Target Release

1.15.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[github-actions]

Changelog Warning

Currently this PR would target a v1.15 release. Please add a changelog entry for in the .changes/v1.15 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[dsa0x]

Thank you for your contribution and investigation @davidspielmann .

In the test below, it seems that the source of the panic is in the test itself

if got := is.Current; got != nil {
	t.Errorf("current is %#v; want nil", got)
}

(is is nil, hence the panic)

I do agree that we should test that case of where the ResourceInstance is nil. However, it would be better if we are testing our method expectations directly

Something like

t.Run("nil resource", func(t *testing.T) {
		var nilRI *ResourceInstance
		dk = nilRI.deposeCurrentObject(NotDeposed)
		t.Logf("deposedKey is %q", dk)

		if dk != NotDeposed {
			t.Errorf("expected NotDeposed, got %q", dk)
		}
	})

What do you think?

[davidspielmann]

Great, thanks a lot for the reply.

I completely agree, your suggested solution is even better!