Repository: kubernetes
Issue: Fake client does not validate if the namespace exists when creating resources
Labels: kind/bug,sig/api-machinery,triage/accepted

### What happened?

When using the fake client provided by the Kubernetes client-go library, I observed that it does not validate whether the namespace exists before creating resources.

For example, in the test case below, I attempted to create a Deployment in a non-existent namespace (test-namespace). However, no error was returned, and the operation succeeded without the namespace being created or verified:

```go
import (
	clientFake "k8s.io/client-go/kubernetes/fake"
	v1 "k8s.io/api/apps/v1"
        "testing"
)

func Test1(t *testing.T) {
    k8sClient := clientFake.NewSimpleClientset()
    _, err := k8sClient.AppsV1().Deployments("test-namespace").Create(context.Background(), &v1.Deployment{
        ObjectMeta: metav1.ObjectMeta{Name: "test-deployment"},
    }, metav1.CreateOptions{})
    fmt.Println(err)
}
```

Running this test produces the following output:
```bash
<nil>
PASS
ok      portrait/offline/pkg/prometheus 0.018s
```

I expected the fake client to return an error indicating that the namespace does not exist. However, it silently allowed the creation of the resource.


### What did you expect to happen?

The fake client should validate whether the specified namespace exists before allowing the creation of a resource within it. If the namespace does not exist, it should return an error similar to the behavior of a real Kubernetes API server.

### How can we reproduce it (as minimally and precisely as possible)?

* Create a fake client using clientFake.NewSimpleClientset().
* Attempt to create a resource (e.g., Deployment) in a non-existent namespace.
* Observe that no error is returned, and the resource is created without namespace validation.

### Anything else we need to know?

* The fake client is commonly used for unit testing in Kubernetes-related projects. If it does not mimic the real Kubernetes API server's behavior accurately, it can lead to tests passing incorrectly and bugs being introduced into production code.
* I understand that the fake client is not a full Kubernetes API server implementation. However, basic validations like namespace existence checks are critical for accurate testing.
* I am happy to submit a PR to address this issue if it is agreed that this is a bug or missing feature. Please let me know if this behavior is intentional or if I should proceed with the fix.
* If the maintainers decide this is not a bug, I would appreciate clarification on whether this behavior is by design or if there are alternative approaches to handle namespace validation in unit tests.

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.31.0
Kustomize Version: v5.4.2
Server Version: v1.21.1
WARNING: version difference between client (1.31) and server (1.21) exceeds the supported minor version skew of +/-1
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

$ uname -a
Linux MI-20240719YHKN 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>