Not able to use MockK in Android Espresso UI Testing - kotlin

I am getting a error when trying to use MockK in UI test which was perfectly working in Unittest cases
MockK could not self-attach a jvmti agent to the current VM
Full error report
Caused by: io.mockk.proxy.MockKAgentException: MockK could not self-attach a jvmti agent to the current VM. This feature is required for inline mocking.
This error occured due to an I/O error during the creation of this agent: java.io.IOException: Unable to dlopen libmockkjvmtiagent.so: dlopen failed: library "libmockkjvmtiagent.so" not found
Potentially, the current VM does not support the jvmti API correctly
at io.mockk.proxy.android.AndroidMockKAgentFactory.init(AndroidMockKAgentFactory.kt:67)
at io.mockk.impl.JvmMockKGateway.<init>(JvmMockKGateway.kt:46)
at io.mockk.impl.JvmMockKGateway.<clinit>(JvmMockKGateway.kt:186)
... 30 more
Caused by: java.io.IOException: Unable to dlopen libmockkjvmtiagent.so: dlopen failed: library "libmockkjvmtiagent.so" not found
at dalvik.system.VMDebug.nativeAttachAgent(Native Method)
at dalvik.system.VMDebug.attachAgent(VMDebug.java:693)
at android.os.Debug.attachJvmtiAgent(Debug.java:2617)
at io.mockk.proxy.android.JvmtiAgent.<init>(JvmtiAgent.kt:48)
at io.mockk.proxy.android.AndroidMockKAgentFactory.init(AndroidMockKAgentFactory.kt:40)
Let me know is there any other way to initialize the MockK to make use in Espresso
When tried to add
androidTestImplementation "org.mockito:mockito-inline:$mockitoVersion"
Observed this error
2 files found with path 'mockito-extensions/org.mockito.plugins.MockMaker'.
Adding a packagingOptions block may help, please refer to
https://developer.android.com/reference/tools/gradle-api/7.2/com/android/build/api/dsl/ResourcesPackagingOptions
for more information
Versions
mockk version = 1.12.4
Android = 32
kotlin_version = '1.6.21'
Code which causes this issue when added in android UI testcases(Espresso)
val presenter = mockk<LoginPresenter>()
val view = mockk<LoginView>()
How to perform a mock api call like this
val presenter = mockk<LoginPresenter>()
val view = mockk<LoginView>()
onView(withId(R.id.button_login)).perform(loginClick())
But i want mock api to be called
instead of loginClick() in perform() can i call some how the below execution
so that my app uses mock api's
or is there any way to make my entire testcase file use mockk data
every { presenter.onLoginButtonClicked("bc#mail.com","Abc123") } returns view.onCognitoLoginSuccess()

For me adding this solved the problem:
android {
testOptions {
packagingOptions {
jniLibs {
useLegacyPackaging = true
}
}
}
}
I found this here. Hope it helps.

Accorfing to here :
Instrumented Android tests are all failing due to issue with mockk
1.12.4
I used io.mockk:mockk-android:1.12.4 and i have same issue..
SOLUTION:
I change the version of io.mockk:mockk-android to 1.12
3 and test runed fine for me
androidTestImplementation "io.mockk:mockk-android:1.12.3"

Related

Android studio JavaDoc error throws a NullPointerException

Android studio cannot create JavaDoc. It throws a null pointer exception and cannot identify any of the android packed items.
...
/home/<user>/AndroidStudioProjects/<project>/app/src/main/java/com/example/simpleparadox/listycity/MainActivity.java:14: error: cannot access ViewGroup
public class MainActivity extends AppCompatActivity {
^
class file for android.view.ViewGroup not found
javadoc: error - fatal error encountered: java.lang.NullPointerException
javadoc: error - Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
java.lang.NullPointerException
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$MembersPhase.runPhase(TypeEnter.java:934)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:282)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$MembersPhase.doCompleteEnvs(TypeEnter.java:877)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:251)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:266)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:266)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:266)
at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.complete(TypeEnter.java:198)
at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:642)
at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1326)
at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:583)
at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:560)
at jdk.javadoc/jdk.javadoc.internal.tool.JavadocEnter.main(JavadocEnter.java:79)
at jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:206)
at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:576)
at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:432)
at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:345)
at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)
7 errors
Then I found a work around which add -bootclasspath path_to_sdk_android_jar_file in the other command-line argument text box in the JavaDoc dialog.
However, newer Java deprecated -bootclasspath. It throws another error as follows:
error: option --boot-class-path not allowed with target 11
So I used -sourcepath instead. That brought the old error (NullPointerException).
I am pretty much lost at this point.
By the way, if I choose a class with only Java elements (no-android) and create JavaDoc to that specific file only, it creates JavaDoc nicely. But this is not a good workaround for a project with a lot of classes.
I've faced the same issue as yours with several imports errors..
The following solution worked for me ( I got it from mike192's answer, see the link here )
task javadoc(type: Javadoc) {
doFirst {
configurations.implementation
.filter { it.name.endsWith('.aar') }
.each { aar ->
copy {
from zipTree(aar)
include "**/classes.jar"
into "$buildDir/tmp/aarsToJars/${aar.name.replace('.aar', '')}/"
}
}
}
configurations.implementation.setCanBeResolved(true)
source = android.sourceSets.main.java.srcDirs
classpath += project.files(android.getBootClasspath().join(File.pathSeparator))
classpath += configurations.implementation
classpath += fileTree(dir: "$buildDir/tmp/aarsToJars/")
destinationDir = file("${project.buildDir}/outputs/javadoc/")
failOnError false
exclude '**/BuildConfig.java'
exclude '**/R.java'
}
All you need to do is to add the code to your build.gradle file right before your dependencies {}
Then, double click on your Ctrl button and execute the following command :
gradle javadoc
The result of the javadoc can be then found in your project's directory \app\build\outputs\javadoc
I hope this works for you

Ktor client NoSuchMethodError

I want to write a telegram bot and use this library from Github for that. In this telegram bot I need to make some requests to another service, so I want to use the ktor client library for that. However when I try to instantiate the ktor httpClient I get the following exception:
Exception in thread "main" java.lang.NoSuchMethodError: 'void io.ktor.util.collections.ConcurrentMap.<init>(io.ktor.util.Lock, int, int, kotlin.jvm.internal.DefaultConstructorMarker)'
at io.ktor.client.engine.cio.CIOEngine.<init>(CIOEngine.kt:32)
at io.ktor.client.engine.cio.CIO.create(CIOCommon.kt:23)
at io.ktor.client.HttpClientKt.HttpClient(HttpClient.kt:42)
at io.ktor.client.HttpClientJvmKt.HttpClient(HttpClientJvm.kt:21)
at io.ktor.client.HttpClientJvmKt.HttpClient$default(HttpClientJvm.kt)
at problem.ktor.MainKt.main(Main.kt:9)
at problem.ktor.MainKt.main(Main.kt)
I made a new project and narrowed the problem down to the telegram bot library, which apparently conflicts with the kotr library. I assume some version conflict of the kotr library, because that's where the exception happens. How can I solve the conflict?
Here is a minimal reproducible example. Use the following build.gradle.kts file:
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
plugins {
application
kotlin("jvm") version "1.4.30"
}
repositories {
mavenCentral()
maven(url = "https://jitpack.io")
}
dependencies {
implementation("io.ktor:ktor-client-core:1.5.2")
implementation("io.ktor:ktor-client-cio:1.5.2")
implementation("com.github.kotlin-telegram-bot:kotlin-telegram-bot:6.0.4")
}
And run the following minimal main function:
import io.ktor.client.*
fun main() {
HttpClient()
}
Maybe it's important, I use Java 15.0.2.
The problematic dependency is com.github.kotlin-telegram-bot.kotlin-telegram-bot:webhook:6.0.4. As a workaround you can exclude it since it's just a sample:
implementation("com.github.kotlin-telegram-bot:kotlin-telegram-bot:6.0.4") {
exclude(module = "webhook")
}

Ktor - post unhanldled error with coroutines

I a new to Kotlin and Ktor in particular, so I have tried to do simple post request. As you can see below, there is nothing special.
routing {
post("/articles/add"){
val post = call.receive<ArticleRequest>()
println(post)
}
Error shown in logs is below and I don't understand why I should use here coroutines.
ERROR Application - Unhandled: POST - /articles/add
java.lang.IllegalStateException: Using blocking primitives on this dispatcher is not allowed. Consider using async channel instead or use blocking primitives in withContext(Dispatchers.IO) instead.
I am using 1.4.2 version. I would appreciate any help.
If you are using Jackson this is a bug and there is a suggested workaround:
routing {
post("/articles/add") {
with(Dispatchers.IO) {
val post = call.receive<ArticleRequest>()
println(post)
}
}
}
Or you can rollback to 1.4.1 until the bug is solved.
I've experienced the same issue after upgrading to ktor 1.4.2 and Kotlin 1.4.20, and I used both Moshi and Gson on this specific project but I don't believe they are causing this issue.
If you have a 'gradle.properties' file, add these ( or whatever version you wish to use ) :
ktor_version=1.3.2
kotlin_version=1.3.70.
Otherwise, in your 'build.gradle' file, create variables for different version :
buildscript {
ext.kotlin_version = '1.3.70'
ext.ktor_version = '1.3.2'
repositories {
jcenter()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
Then sync your gradle, run project.. all should be good.
However if you still experience some gradle-related issue, try this :
go to gradle (folder) -> wrapper -> open gradle_wrapper.properties and make sure the url has version 6.x.x or 5.x.x.
Mine looks like this currently:
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-6.6.1-all.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

How to properly test web socket connection with KotlinJS

I'm unable to test my code that uses a native WebSocket. This is the body of the test function:
val webSocket = WebSocket("ws://localhost:8888")
window.setTimeout({
assertEquals(WebSocket.OPEN, webSocket.readyState)
}, 1000)
I'm using Karma with Mocha test runner. The following code executes without any errors, but the setTimeout is actually ignored and never executed.
Mocha seems to support setTimeout-based tests with the --delay. However, when I use the flag with client: { mocha: { delay: true } } Karma configuration, the tests just freeze and fail, outputting the following cause message:
Disconnected, because no message in 60000 ms.
What is the correct way to execute tests with setTimeout? If this is tricky, is there any other way I can perform assertions on the WebSocket after it's fully connected? I don't use any Mocha-specific features yet, so I don't mind changing the framework.
Returning Promise from your #Test function should do the trick.
Something like:
#Test fun testWebSocket() = Promise<Unit> { resolve, reject ->
val webSocket = WebSocket("ws://localhost:8888")
window.setTimeout({
assertEquals(WebSocket.OPEN, webSocket.readyState)
resolve(Unit)
}, 1000)
}
If you want to test async code, you need to tell the test framework when the test is done.
See this answer.

Realm throws exception with empty unit test

In an Objective-C project, we started writing our new Unit Tests in Swift. I'm just now trying to create our first Unit Test of successfully saving the results of a parsed JSON. However, the test already fails during setup() due to the following error:
[ProjectTests.Project testInitializingOverlayCollectionCreatesAppropriateRealmObjects] : failed: caught "NSInvalidArgumentException", "+[RLMObjectBase ignoredProperties]: unrecognized selector sent to class 0x759b70
So apparently it tries to execute ignoredProperties on the RLMObjectBase class, and that method isn't implemented yet. Not sure how this happens, because I have yet to initialise anything, beyond creating a RLMRealms object with a random in-memory identifier.
ProjectTests.swift
import XCTest
class ProjectOverlayCollectionTests: XCTestCase {
var realm: RLMRealm!
override func setUp() {
super.setUp()
// Put setup code here. This method is called before the invocation of each test method in the class.
let realmConfig = RLMRealmConfiguration()
realmConfig.inMemoryIdentifier = NSUUID().UUIDString
do {
realm = try RLMRealm(configuration: realmConfig) // <-- Crashes here.
}
catch _ as NSError {
XCTFail()
}
}
override func tearDown() {
// Put teardown code here. This method is called after the invocation of each test method in the class.
super.tearDown()
}
func testInitializingOverlayCollectionCreatesAppropriateRealmObjects() {
XCTAssertTrue(true)
}
}
Project-Bridging-Header.h
#import <Realm/Realm.h>
Podfile
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '7.1'
def shared_pods
pod 'Realm', '0.95.0'
end
target 'Project' do
shared_pods
end
target 'ProjectTests' do
shared_pods
end
As mentioned in the Realm documentation;
Avoid Linking Realm and Tested Code in Test Target
Remove the Realm pod from the ProjectTests target and all is right with the world.
Update: This answer is outdated. As #rommex mentions in a comment, following the current Realm installation documentation should link it to both your module and test targets without problems. However, I have not checked this.