Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilizing nullability in relaxed mock #642

Closed
hrach opened this issue Jun 15, 2021 · 3 comments · Fixed by #643
Closed

Utilizing nullability in relaxed mock #642

hrach opened this issue Jun 15, 2021 · 3 comments · Fixed by #643

Comments

@hrach
Copy link
Contributor

hrach commented Jun 15, 2021

Expected Behavior

We're migrating from Mockito and one of the biggest differences is that the relaxed mock is returning always a value, even if the method has a nullable return type.

We consider it a nice feature not to redefine methods we do not care and wanna let the code handle the default, which is rather a null than empty object (list/map/0/"").

Would you be open to add this behavior to MockK (I would try to make PR)?

Since this would be a great BC break, it should be probably configurable. Ideally the same way as the relax behavior:

  • via function argument (~mockk(relaxWithNulls = true))
  • via project-wide configuration

Current Behavior

        class Foo {
            fun getSomething(): Int? {
                return 1
            }
        }

        val mock = mockk<Foo>(relaxed = true) 
        assertEquals(null, mock.getSomething()) // fails, returns 0 currently
@Raibaz
Copy link
Collaborator

Raibaz commented Jun 15, 2021

Not sure about this: although it would be rather easy to implement, I think it's right for the AnyValueGenerator to return a default, non-null value for relaxed mocks.

In my opinion, it feels more Kotlin-idiomatic to return a non-null value by default and ave users explicitly specify when they want a nullable return value to be null.

I'll have to think about this.

@hrach
Copy link
Contributor Author

hrach commented Jun 16, 2021

I think it's right for the AnyValueGenerator to return a default, non-null value for relaxed mocks.

Maybe that's an alternative way - allow creating custom anyValueGenerator (and also pass the proper nullability information to it).

In my opinion, it feels more Kotlin-idiomatic to return a non-null value by default

I would probably disagree but yet I'd say having idiomatic unit tests is not the motivation here: we have a lot of units tests depending on this behavior and it would ease our migration a lot.

More I think about this the custom anyValueGenerator would be probably a better choice.

@Raibaz
Copy link
Collaborator

Raibaz commented Jun 16, 2021

Makes sense, i like the approach of being able to provide a custom anyValueGenerator, thanks for this and for the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants