Why aren't “internal” types in the main source tree visible in my unit tests?
up vote
2
down vote
favorite
I've got a Kotlin project in IntelliJ that is structured like this:
- main/com/foo/Bar.kt
- test/com/foo/BarTest.kt
where Bar is defined as:
internal class Bar
and BarTest is something like:
class BarTest {
private lateinit var bar: Bar
}
I'm getting compiler errors in IntelliJ on the reference to Bar with the message:
Cannot access 'Bar': it is internal in 'com.foo'
The tests, however, compile and run from the command line (via Gradle).
How can I suppress/remove this error when using IntelliJ?
My setup is:
- macOS 10.14.1
- IntelliJ 2018.2.6
- Kotlin 1.3.10
intellij-idea kotlin
asked Nov 19 at 0:50
homerman
1,9871718
add a comment |
up vote
2
down vote
favorite
I've got a Kotlin project in IntelliJ that is structured like this:
- main/com/foo/Bar.kt
- test/com/foo/BarTest.kt
where Bar is defined as:
internal class Bar
and BarTest is something like:
class BarTest {
private lateinit var bar: Bar
}
I'm getting compiler errors in IntelliJ on the reference to Bar with the message:
Cannot access 'Bar': it is internal in 'com.foo'
The tests, however, compile and run from the command line (via Gradle).
How can I suppress/remove this error when using IntelliJ?
My setup is:
- macOS 10.14.1
- IntelliJ 2018.2.6
- Kotlin 1.3.10
intellij-idea kotlin
asked Nov 19 at 0:50
homerman
1,9871718
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using thebuild.gradleas the source? Maybe recreate your project by opening thebuild.gradleto see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.
– Jayson Minard
Nov 19 at 5:04
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I've got a Kotlin project in IntelliJ that is structured like this:
- main/com/foo/Bar.kt
- test/com/foo/BarTest.kt
where Bar is defined as:
internal class Bar
and BarTest is something like:
class BarTest {
private lateinit var bar: Bar
}
I'm getting compiler errors in IntelliJ on the reference to Bar with the message:
Cannot access 'Bar': it is internal in 'com.foo'
The tests, however, compile and run from the command line (via Gradle).
How can I suppress/remove this error when using IntelliJ?
My setup is:
- macOS 10.14.1
- IntelliJ 2018.2.6
- Kotlin 1.3.10
intellij-idea kotlin
asked Nov 19 at 0:50
homerman
1,9871718
I've got a Kotlin project in IntelliJ that is structured like this:
- main/com/foo/Bar.kt
- test/com/foo/BarTest.kt
where Bar is defined as:
internal class Bar
and BarTest is something like:
class BarTest {
private lateinit var bar: Bar
}
I'm getting compiler errors in IntelliJ on the reference to Bar with the message:
Cannot access 'Bar': it is internal in 'com.foo'
The tests, however, compile and run from the command line (via Gradle).
How can I suppress/remove this error when using IntelliJ?
My setup is:
- macOS 10.14.1
- IntelliJ 2018.2.6
- Kotlin 1.3.10
intellij-idea kotlin
intellij-idea kotlin
asked Nov 19 at 0:50
homerman
1,9871718
asked Nov 19 at 0:50
homerman
1,9871718
asked Nov 19 at 0:50
homerman
1,9871718
asked Nov 19 at 0:50
homerman
1,9871718
asked Nov 19 at 0:50
homerman
1,9871718
1,9871718
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using thebuild.gradleas the source? Maybe recreate your project by opening thebuild.gradleto see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.
– Jayson Minard
Nov 19 at 5:04
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06
add a comment |
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using thebuild.gradleas the source? Maybe recreate your project by opening thebuild.gradleto see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.
– Jayson Minard
Nov 19 at 5:04
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using the
build.gradle as the source? Maybe recreate your project by opening the build.gradle to see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.– Jayson Minard
Nov 19 at 5:04
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using the
build.gradle as the source? Maybe recreate your project by opening the build.gradle to see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.– Jayson Minard
Nov 19 at 5:04
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
I opened up two projects concurrently using the same IntelliJ installation:
- a former project in which I was able to unit test an
internalclass located in themainsource tree (all within the boundaries of the same IntelliJ module) - the current project in which I was unable to reproduce this setup
The fact that IntelliJ still gave no errors in the former setup led me to conclude the issue was not to do with my IntelliJ setup. As @JaysonMinard suggested, I looked at the differences in the Gradle configuration.
The difference was in the current project's top-level settings.gradle, I use the convention of renaming modules, a la:
findProject(':module-blah')?.name = 'blah'
...so as to refer to my Gradle projects by shorter names while having them listed contiguously in my project browser (rather than being scattered around with other files alphabetically). Removing this shortcut restored the behavior I was looking for in my unit tests.
answered Nov 19 at 6:09
homerman
1,9871718
interestingly enough... as I mentioned, I removed the line to rename the project viafindProject()and IntelliJ doesn't complain about the reference to theinternalclass from the unit test... and if I restore thefindProject()line everything continues to work... ¯_(ツ)_/¯
– homerman
Nov 20 at 2:13
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I opened up two projects concurrently using the same IntelliJ installation:
- a former project in which I was able to unit test an
internalclass located in themainsource tree (all within the boundaries of the same IntelliJ module) - the current project in which I was unable to reproduce this setup
The fact that IntelliJ still gave no errors in the former setup led me to conclude the issue was not to do with my IntelliJ setup. As @JaysonMinard suggested, I looked at the differences in the Gradle configuration.
The difference was in the current project's top-level settings.gradle, I use the convention of renaming modules, a la:
findProject(':module-blah')?.name = 'blah'
...so as to refer to my Gradle projects by shorter names while having them listed contiguously in my project browser (rather than being scattered around with other files alphabetically). Removing this shortcut restored the behavior I was looking for in my unit tests.
answered Nov 19 at 6:09
homerman
1,9871718
interestingly enough... as I mentioned, I removed the line to rename the project viafindProject()and IntelliJ doesn't complain about the reference to theinternalclass from the unit test... and if I restore thefindProject()line everything continues to work... ¯_(ツ)_/¯
– homerman
Nov 20 at 2:13
add a comment |
up vote
1
down vote
accepted
I opened up two projects concurrently using the same IntelliJ installation:
- a former project in which I was able to unit test an
internalclass located in themainsource tree (all within the boundaries of the same IntelliJ module) - the current project in which I was unable to reproduce this setup
The fact that IntelliJ still gave no errors in the former setup led me to conclude the issue was not to do with my IntelliJ setup. As @JaysonMinard suggested, I looked at the differences in the Gradle configuration.
The difference was in the current project's top-level settings.gradle, I use the convention of renaming modules, a la:
findProject(':module-blah')?.name = 'blah'
...so as to refer to my Gradle projects by shorter names while having them listed contiguously in my project browser (rather than being scattered around with other files alphabetically). Removing this shortcut restored the behavior I was looking for in my unit tests.
answered Nov 19 at 6:09
homerman
1,9871718
interestingly enough... as I mentioned, I removed the line to rename the project viafindProject()and IntelliJ doesn't complain about the reference to theinternalclass from the unit test... and if I restore thefindProject()line everything continues to work... ¯_(ツ)_/¯
– homerman
Nov 20 at 2:13
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I opened up two projects concurrently using the same IntelliJ installation:
- a former project in which I was able to unit test an
internalclass located in themainsource tree (all within the boundaries of the same IntelliJ module) - the current project in which I was unable to reproduce this setup
The fact that IntelliJ still gave no errors in the former setup led me to conclude the issue was not to do with my IntelliJ setup. As @JaysonMinard suggested, I looked at the differences in the Gradle configuration.
The difference was in the current project's top-level settings.gradle, I use the convention of renaming modules, a la:
findProject(':module-blah')?.name = 'blah'
...so as to refer to my Gradle projects by shorter names while having them listed contiguously in my project browser (rather than being scattered around with other files alphabetically). Removing this shortcut restored the behavior I was looking for in my unit tests.
answered Nov 19 at 6:09
homerman
1,9871718
I opened up two projects concurrently using the same IntelliJ installation:
- a former project in which I was able to unit test an
internalclass located in themainsource tree (all within the boundaries of the same IntelliJ module) - the current project in which I was unable to reproduce this setup
The fact that IntelliJ still gave no errors in the former setup led me to conclude the issue was not to do with my IntelliJ setup. As @JaysonMinard suggested, I looked at the differences in the Gradle configuration.
The difference was in the current project's top-level settings.gradle, I use the convention of renaming modules, a la:
findProject(':module-blah')?.name = 'blah'
...so as to refer to my Gradle projects by shorter names while having them listed contiguously in my project browser (rather than being scattered around with other files alphabetically). Removing this shortcut restored the behavior I was looking for in my unit tests.
answered Nov 19 at 6:09
homerman
1,9871718
answered Nov 19 at 6:09
homerman
1,9871718
answered Nov 19 at 6:09
homerman
1,9871718
answered Nov 19 at 6:09
homerman
1,9871718
1,9871718
interestingly enough... as I mentioned, I removed the line to rename the project viafindProject()and IntelliJ doesn't complain about the reference to theinternalclass from the unit test... and if I restore thefindProject()line everything continues to work... ¯_(ツ)_/¯
– homerman
Nov 20 at 2:13
add a comment |
interestingly enough... as I mentioned, I removed the line to rename the project viafindProject()and IntelliJ doesn't complain about the reference to theinternalclass from the unit test... and if I restore thefindProject()line everything continues to work... ¯_(ツ)_/¯
– homerman
Nov 20 at 2:13
interestingly enough... as I mentioned, I removed the line to rename the project via
findProject() and IntelliJ doesn't complain about the reference to the internal class from the unit test... and if I restore the findProject() line everything continues to work... ¯_(ツ)_/¯– homerman
Nov 20 at 2:13
interestingly enough... as I mentioned, I removed the line to rename the project via
findProject() and IntelliJ doesn't complain about the reference to the internal class from the unit test... and if I restore the findProject() line everything continues to work... ¯_(ツ)_/¯– homerman
Nov 20 at 2:13
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53366990%2fwhy-arent-internal-types-in-the-main-source-tree-visible-in-my-unit-tests%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
There's some debate, but the consensus seems to be that you should only write unit tests for the public API. At the very least, any tests you write against non-public code shouldn't be considered part of your production test suite.
– Kevin Krumwiede
Nov 19 at 0:57
the thing is i've setup projects like this in the past (i'm looking back at them through GitHub). i recently re-installed everything from my OS on up, so figured maybe i either missed some IntelliJ configuration setting that i had applied before, or that maybe the most recent build has started to employ this behavior.
– homerman
Nov 19 at 1:09
Technically it is allowed (internal spans main/test in the same module) and there must be a misconfiguration somewhere. Or you are not in the same IntelliJ module for the main/test aspects of your project? Did you create your project using the
build.gradleas the source? Maybe recreate your project by opening thebuild.gradleto see if you fix it. (and check the modules) ... showing your directory structure would help, as well as the build file.– Jayson Minard
Nov 19 at 5:04
So, you know it normally works, and only you have enough evidence to know what is different than the normal. Compare it to your previous projects, check modules, see what is different.
– Jayson Minard
Nov 19 at 5:06