[go: nahoru, domu]

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

Overriding final of AtomicBoolean type doesn't work #247

Open
TheFriendlyCoder opened this issue Oct 28, 2022 · 3 comments
Open

Overriding final of AtomicBoolean type doesn't work #247

TheFriendlyCoder opened this issue Oct 28, 2022 · 3 comments
Assignees
Labels
feature request Issues requesting a new feature

Comments

@TheFriendlyCoder
Copy link

I have been experimenting with Spock lately as a potential replacement for JUnit / Mockito in some unit tests I am working on and have been struggling with mocking of classes that have final fields and methods. I was hoping this Spock plugin might address at least some of my problems, but I can not get a very simple POC Spock test to work properly. The simplest example test I've found is shown below:

import java.util.concurrent.atomic.AtomicBoolean

@Mockable(AtomicBoolean)
class SampleTestSpec extends Specification {
    def "Test Final Mock" () {
        given:
        AtomicBoolean activeFlag = Mock(AtomicBoolean.class)
        activeFlag.get() >> [true, false]

        expect:
        // First true
        activeFlag.get()
        // Then false
        !activeFlag.get()
    }
}

I am quite new to Java and Spock so I am wondering if I am just doing something fundamentally wrong here, or if this is perhaps a bug with this plugin?

@joke
Copy link
Owner
joke commented Oct 29, 2022

Hi @TheFriendlyCoder,

that's a bit tricky. First of all the syntax is wrong. You either need to write

given:
    AtomicBoolean activeFlag = Mock(AtomicBoolean.class) {
        activeFlag.get() >> [true, false]
    }

or

given:
    AtomicBoolean activeFlag = Mock(AtomicBoolean.class) 
then:
    activeFlag.get() >> [true, false]

Other than that you can not get a value from a mock in the expect block.
You can check for yourself if you create a minimal non final AtomicBoolean class. The specification isn't working in bare spock either.

public class AtomicBoolean {
    public boolean get() {
        return false;
    }
}

But even if you would this your specification AtomicBoolean can currently. Classes must not be loaded before trying to transform them. Unfortunately AtomicBoolean is loaded during startup by ByteBuddy itself before the mock transformation can kick in.
This might change in future releases.

Regards
Joke

@joke joke added the waiting for feedback Waiting for feedback issue/pr author label Oct 29, 2022
@joke joke self-assigned this Oct 30, 2022
@TheFriendlyCoder
Copy link
Author

Thanks for the prompt reply.

So does this mean that mocking finals in the Java standard library is basically not supported by this plugin? Also, in your reply you suggested that this "might change in the future" - do you have a link to a feature request or future improvement that I could watch for progress updates on this plan?

@joke
Copy link
Owner
joke commented Nov 2, 2022

It's a little bit trickier than that.

Classes that are loaded before the agent starts can not be altered. So the restriction applies to some Java standard library classes but not all. Only classes used by ByteBuddy, the startup process of JUnit and maybe the built system.
Basically it's a restriction on how this plugin works: Classes get altered during start so spock get do its normal mocking. The plugin does impose an alternative mocking mechanism. I should extend the section in the README.

Let's just put a feature label on this issue. But to be precise I don't see how to see how to implement this feature at the moment.

I'm currently working on a mechanism that mocked classes are detected automatically rather than using the @Mockable annotation

@joke joke added feature request Issues requesting a new feature and removed waiting for feedback Waiting for feedback issue/pr author labels Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issues requesting a new feature
Projects
None yet
Development

No branches or pull requests

2 participants