cucumber / cucumber/cucumber-ruby

Namespaced worlds cannot access each other

Open
#1,627 3 comments 0 reactions 0 assignees View on GitHub
:bug: bug
Dominant language
Ruby
Stars
5.2k
Forks
1.1k
Avg merge
1d 16h
Merged PRs (30d)
3

Description

### 👓 What did you see?

Constructed a pair of namespaced worlds, in which one internally used the other to manage some common resources. Both worlds were observed to be defined and non-`nil` within test steps. Within each world instance however, the other world were observed to be defined, but `nil`.

### ✅ What did you expect to see?

Expected either:
- neither world to have the other defined as a local
- both worlds to have the other defined, and set to the correct global instance

### 📦 Which tool/library version are you using?

- ruby-cucumber, v8.0.0.rc.1
- ruby, v3.0.0
- Ubuntu 20.04 LTS, running kernel 5.4.0

### 🔬 How could we reproduce it?

1. Create the following feature file
```cucumber
Feature: Namespaced worlds can access each other
Scenario: World A can access the instance of World B
Given the test step sees world B as non nil
Then the instance of world A sees the instance of world B the same as the test step sees world B

Scenario: World B can access the instance of World A
Given the test step sees world A as non nil
Then the instance of world B sees the instance of world A the same as the test step sees world A
```

2. Create the following step definition
```ruby
module WorldA
def observe_b
world_b
end
end

module WorldB
def observe_a
world_a
end
end

World(world_a: WorldA, world_b: WorldB)

Given /^the test step sees world A as non nil$/ do
expect(world_a).to_not be nil
end

Given /^the test step sees world B as non nil$/ do
expect(world_b).to_not be nil
end

Then /^the instance of world A sees the instance of world B the same as the test step sees world B$/ do
expect(world_a.observe_b).to be world_b
end

Then /^the instance of world B sees the instance of world A the same as the test step sees world A$/ do
expect(world_b.observe_a).to be world_a
end
```

3. Run the tests, and observe the following results:
```text
$ cucumber --quiet
Feature: Namespaced worlds can access each other

Scenario: World A can access the instance of World B
Given the test step sees world B as non nil
Then the instance of world A sees the instance of world B the same as the test step sees world B

expected # => #
got # => nil

Compared using equal?, which compares object identity,
but expected and actual are not the same object. Use
`expect(actual).to eq(expected)` if you don't care about
object identity in this example.

(RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/namespaced_world.rb:24:in `/^the instance of world A sees the instance of world B the same as the test step sees world B$/'
features/namespaced_world.feature:4:in `the instance of world A sees the instance of world B the same as the test step sees world B'

Scenario: World B can access the instance of World A
Given the test step sees world A as non nil
Then the instance of world B sees the instance of world A the same as the test step sees world A

expected # => #
got # => nil

Compared using equal?, which compares object identity,
but expected and actual are not the same object. Use
`expect(actual).to eq(expected)` if you don't care about
object identity in this example.

(RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/namespaced_world.rb:28:in `/^the instance of world B sees the instance of world A the same as the test step sees world A$/'
features/namespaced_world.feature:8:in `the instance of world B sees the instance of world A the same as the test step sees world A'

Failing Scenarios:
cucumber features/namespaced_world.feature:2
cucumber features/namespaced_world.feature:6

2 scenarios (2 failed)
4 steps (2 failed, 2 passed)
```

### 📚 Any additional context?

This issue arose while looking at factoring out common behaviours from some namespaced worlds to one consolidated spot. The intent was to have all of the other worlds access the common world to get access to the shared behaviour. This appeared to be a valid refactoring, since with non-namespaced worlds, each world is able to access the other methods introduced by the others.

There does not appear to be any documentation indicating that this should or should not be possible.

----

*This text was originally generated from a [template](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates), then edited by hand. [You can modify the template here.](https://github.com/cucumber/.github/edit/main/.github/ISSUE_TEMPLATE/bug_report.md)*

Contributor guide

Open the contributing guide

Research direction

Start by running the namespaced-world feature and step definitions shown in the issue to reproduce the two failing identity checks. Trace how World(world_a: WorldA, world_b: WorldB) exposes each world instance, then add regression coverage ensuring each namespaced world can access the other; done when both scenarios pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
testing
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.