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.

Sign up for GitHub

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

Implement inner spec #1102

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Implement inner spec #1102

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7f59b07
feat: update setInner to use lambda receiver for cleaner DSL
soonhong99 Nov 21, 2024
d8224bb
test: Add verification for CustomObject's `value` property in InnerSpec
soonhong99 Nov 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion ...y-kotlin/src/main/kotlin/com/navercorp/fixturemonkey/kotlin/ArbitraryBuilderExtensions.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ import com.navercorp.fixturemonkey.customizer.InnerSpec
* Apply manipulation to [InnerSpec][com.navercorp.fixturemonkey.customizer.InnerSpec]
* and pass it to [setInner][com.navercorp.fixturemonkey.ArbitraryBuilder.setInner].
*/
fun <T> ArbitraryBuilder<T>.setInner(innerSpecConfigurer: ((InnerSpec) -> Unit)): ArbitraryBuilder<T> {
fun <T> ArbitraryBuilder<T>.setInner(innerSpecConfigurer: InnerSpec.() -> Unit): ArbitraryBuilder<T> {
return this.setInner(InnerSpec().apply(innerSpecConfigurer))
}

Expand Down
18 changes: 17 additions & 1 deletion ...ts/kotlin-tests/src/test/kotlin/com/navercorp/fixturemonkey/tests/kotlin/InnerSpecTest.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,17 +32,33 @@ class InnerSpecTest {
fun setInnerSpecByTrailingLambda() {
val actual = SUT.giveMeBuilder<Map<String, String>>()
.setInner {
it.keys("key1", "key2")
keys("key1", "key2")
.minSize(3)
}
.sample()

then(actual).containsKeys("key1", "key2")
}

@RepeatedTest(TEST_COUNT)
fun setInnerSpecWithCustomObject() {
val actual = SUT.giveMeBuilder<Map<String, CustomObject>>()
.setInner {
size(1)
entry("key") {
property("value", "expected")
}
Comment on lines +48 to +50
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

해당 property를 설정할 때 propertyName은 "value", value는 "expected"로 명시적으로 설정하고 있습니다.

그런데 .sample()을 호출하면, Fixture Monkey의 랜덤 데이터 생성 로직에 따라 CustomObject.value가 랜덤 값으로 채워지는 것 같습니다. 이 경우 "expected"라는 값은 실질적으로 적용되지 않고 다른 랜덤 값으로 덮어씌워질 가능성이 있는데요.

그렇다면, "expected" 값을 명시적으로 설정할 수 있도록 설계한 이유가 무엇인지 궁금합니다. 이 설정이 랜덤 데이터 생성 과정에서 어떤 역할을 하며, 왜 이러한 구조가 필요했는지 알고 싶습니다.

Copy link
Contributor

@seongahjo seongahjo Nov 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

랜덤 값으로 채워지는 결과가 나왔다면 receiver가 가르키는 대상이 달라지면서 기존과 동작이 달라지게 된 게 아닌가 싶은데요.
원래 기본적인 set API은 고정된 값을 설정해야할 때 사용하는 API입니다.
아마 동작이 기존과 다르게 랜덤하게 나와서 헷갈리셨을 것 같습니다.

원래 동작은 아래와 같습니다. 아래 검증문이 항상 성립하게 됩니다.

val actual = SUT.giveMeBuilder<Map<String, CustomObject>>()
            .setInner { m ->
                m.size(1)
                m.entry("key") { e ->
                    e.property("value", "expected")
                }
            }
            .sample()

        then(actual.values.first().value).isEqualTo("expected")

m의 scope 내에서는 m이 this가 되고, e 의 scope 내에서는 e가 this가 되는 방향으로 구현이 되야됩니다.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

랜덤 값으로 채워지는 결과가 나왔다면 receiver가 가르키는 대상이 달라지면서 기존과 동작이 달라지게 된 게 아닌가 싶은데요. 원래 기본적인 set API은 고정된 값을 설정해야할 때 사용하는 API입니다. 아마 동작이 기존과 다르게 랜덤하게 나와서 헷갈리셨을 것 같습니다.

원래 동작은 아래와 같습니다. 아래 검증문이 항상 성립하게 됩니다.

val actual = SUT.giveMeBuilder<Map<String, CustomObject>>()
            .setInner { m ->
                m.size(1)
                m.entry("key") { e ->
                    e.property("value", "expected")
                }
            }
            .sample()

        then(actual.values.first().value).isEqualTo("expected")

m의 scope 내에서는 m이 this가 되고, e 의 scope 내에서는 e가 this가 되는 방향으로 구현이 되야됩니다.

아하 그렇군요! 그렇다면 제가 구현한 방식은 잘못된 구현방식일까요?
then(actual.values.first().value).isEqualTo("expected")
해당 then 구절이 항상 성립하는 방향으로 구현해야할까요?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵, 아래 then 구절이 성립하는 방향으로 구현해야 합니다.

InstantiatorDslSpec 구현을 참조해보시면 좋을 것 같습니다.
아래와 같이 사용할 수 있습니다.

  val actual = SUT.giveMeBuilder<JavaConstructorTestSpecs.JavaTypeObject>()
            .instantiateBy {
                constructor {
                    javaBeansProperty {
                        filter { "string" != it.name }
                    }
                }
            }
            .sample()

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵, 아래 then 구절이 성립하는 방향으로 구현해야 합니다.

InstantiatorDslSpec 구현을 참조해보시면 좋을 것 같습니다. 아래와 같이 사용할 수 있습니다.

  val actual = SUT.giveMeBuilder<JavaConstructorTestSpecs.JavaTypeObject>()
            .instantiateBy {
                constructor {
                    javaBeansProperty {
                        filter { "string" != it.name }
                    }
                }
            }
            .sample()

해당 내용 자세히 설명해주셔서 감사합니다! 말씀해주신 내용대로 동작할 수 있도록 수정하겠습니다.

}
.sample()

then(actual).isNotNull
}

companion object {
private val SUT: FixtureMonkey = FixtureMonkey.builder()
.plugin(KotlinPlugin())
.build()
}
}

data class CustomObject(val value: String)
Loading