I inherited an android project to setup code coverage for. Not having done much for android and almost as little in gradle, I embarked on a quest to find a helpful tutorial. As surprises go, the first few tutorials were very helpful and I was able to include the jacoco gradle plugin and enable the code coverage. Using jenkins I even generated a coverage report. So far everything looks fine.
However, upon setting my eyes on the report, I smelled something fishy. The test vs coverage ratio seemed to be far too small. Further investigation revealed the culprit.
The tests itself are written more as functional not unit ones. That would be ok. However, the project library has no tests in its module. Instead the library tests are written in the gui module (as that is where the library is used).
Therefore, even though most of the library functionality is covered by tests, coverage is generated for stuff from gui module only.
Project
-- Gui module
---- gui sources
---- all the tests
-- Library module
---- library sources
No I have been looking for a working solution quite some time. Unfortunately, all I was able to find was how to combine unit and integration .exec test coverage results into one report (or other unit test based solutions - none of which worked for the instrumentation ones).
What I need, is generate coverage for sources from Library module based on Gui module tests.
As I am stumbling in a dark here, is even anything like that, remotely possible?
For anyone reading this... if you have the same issue, it is time to start banging your head against the wall...
Today I was lucky enough to stumble upon this: https://issuetracker.google.com/issues/37004446#comment12
The actual "problem" seems to be, that library projects are "always" of release type. Therefore they do not contain "necessary instrumentation setup" (unless you enable code coverage for release as well, although I haven't tested it).
So the solution is to specifically enable, in the library to be published, "debug" build (as mentioned, default is the release type):
android {
publishNonDefault true
}
Then, in the project that uses library, specify a debugCompile dependency (release compile can use the "default" release configuration):
dependencies {
debugCompile project(path: 'library', configuration: 'debug')
releaseCompile project('library')
}
And of course (this one I take for granted), remember to enable test coverage for the library:
android {
buildTypes {
debug {
testCoverageEnabled true
}
}
}
Related
Why is compiling and running Kotlin extremely slow (at least on my machine)? I have the latest version of Kotlin compiler installed on my machine.
Specifically the command:
kotlinc main.kt -include-runtime -d main.jar && java -jar main.jar
It's so slow that printing "hello word" takes up to 9 seconds.
I initially thought that it is slow by default (I used dDcoder app) but now I've used the online playground and Sololearn it's much more faster.
My PC is running Windows 10 with Core i5 and 4GB RAM.
This is usually a common complaint among Kotlin users, especially when compiling a project for the first time. Unfortunately, there's nothing you can do about it, your PC spec is sufficient for an effective build and run of Kotlin project.
My advice, for offline compiling, use Intellij IDEA. This IDE has the most efficient support for Kotlin... as it is produced and managed by Jetbrains.
If you use Intellij IDEA already, The project will take less time to compile from first build.
I had the same complaint when I started working with Kotlin from Java. Java's compile time is faster, and there's nothing you can do about the compile time difference as of the present.
Maybe I'm biased, but I think it is unusual to compile Kotlin code this way, so it is not that well optimized. Usually, we use either IntelliJ or Gradle (or Maven), not kotlinc directly. Gradle can cache compiled code, it can run a background daemon to not re-initialize everything with each build, etc.
If we create a Gradle project, even consisting of several submodules, with some multiplatform modules, etc. then running it repeatedly with minor changes takes less than a second each. Even if changes are spread among several submodules, so Gradle has to build all of them.
Having said that, compilation time is a common problem in Kotlin right now. I believe optimizations are somewhere near the top of the Kotlin team priority list, so hopefully we'll see some improvement in the near future. As for now, it is considered a problem for some people.
I had a question regarding the Test APK topic.
Is there a way to use the tests/RunApkTests.targets and
build-tools/scripts/TestApks.targets
files. so I can reuse the targets to run my own android unit tests and get results as part as our continuous integration?
I tried using the NUnit Tutorial with no success. I also created an issue here but I kept researching and found some potentially useful targets there.
I'd rather use these targets through a nuget package as opposed to manually downloading the target files and their associated files.
Any suggestions?
Thank you for your time!
I wonder if it is possible to make an Objective-C project (no UI, no simulator is needed, hosted on Github) to be built on Travis?
Current Travis docs seems not to contain any information regarding the option to have Objective-C projects built on Travis.
But Building a C Project says that:
Travis VMs are 32 bit and currently provide
gcc 4.6
clang 3.1
core GNU build toolchain (autotools, make), cmake, scons
and that default test script is run like
./configure && make && make test
So, to rephrase the subject question:
Do any workarounds exist to make SenTestingKit test suite, that my project currently uses, behave like a C test suite, so it could be treated as such by Travis VM?
NOTE 1: Here is the list of resources, which seem to be related to the question:
Compiling Objective-C without a GUI. It claims that Both gcc and clang compile Objective-C 2.0 and that sounds very promising!
NOTE 2: I suspect that it is possible to use some testing tool other than SenTestingKit:
this tool should be easy to be run without a GUI and without xcodebuild etc: I've opened related issue for that: Is there any non-Xcode-based command line testing tool for Objective-C?. I am even thinking about writing an easy one just to be used by my project.
A few days Travis announced that they are now also supporting objetive-c projects. See Building An Objective-C Project for more info.
Update
It is even possible to make Travis launch the simulator so that you can run application tests and UI related stuff. I required a little extra work, but it's pretty straight forward. I wrote about it here.
I am trying to bring the magic of Cocoapods to my company, but it has hit a tiny snag. We need to be able to unit test code that comes from Cocoapods.
So, my question is, has anyone else encountered this in their company (or is anyone just paranoid enough to care about unit testing this code and figured out how?). It may not be a deal breaker for us, but it will definitely help smooth things over with management if I have this sorted ahead of time.
We could probably insert the tests in the client app, but thats an awful lot of manual work considering we would use pods to reduce manual work. It would be nice to do it once somehow.
In my Podfile I use something like this: link_with ['Sail', 'Sail-Tests']
This links all my Pods with both my normal target and my test target. Then from my tests I can import and test whatever I want. This may overlap with 'inserting the tests in the client app' though.
If you would like to use a setup similar to the one created by Xcode (where the testing target depends on the one under test), another alternative is:
pod 'ObjectiveSugar', '~> 0.5'
target :test, :exclusive => true do
pod 'OCMock', '~> 2.0.1'
end
Marking a target exclusive indicates that it shouldn't inherit the dependencies of the parent. This prevents the duplicate symbol error with this setup.
I use Cocoapods to centralize the core functionality of a whole suite of over 20 apps, that are whitelabeled version of the same 'base' app. For this, I've setup a structure of two Xcode projects.
The first contains the core functionality including the unit tests verifying the expected behavior (Kiwi in my case). The specs as well as the xcodeproj don't show up in the podspec, but the project is tested under CI (Jenkins).
The second project contains the whitelabeled app (one project per app), and it has the dependency to the first project setup via the Podfile. In this light weight app are also Kiwi specs, that only test any custom code for that specific app. It does not test the core classes anymore, because they are already covered. This project is also under CI.
So the main answer-to-your-question part is that your library does not merely contain the source files necessary for the depending project, but also a compiling Xcode project (app or library) that runs the unit tests.
As far as I see every time I make a change, for example the value of a configuration variable, I have to
Make a copy of the change in each project (webapp, Android, IPhone, etc.)
Build each project
Distribute each project (besides the webapp)
I have found PhoneGap build which seems to be a great solution for the mobile part. But it's still beta and it doesn't solve everything. I still have webapp's code, which is not exactly the same.
Do you know techniques, tools or tricks, which help to improve this process?
Thanks in advance.
We are currently developing a web/Android app using PhoneGap and Sencha Touch (iOS is coming soon). So far our approach is as follows:
We have one project per platform plus several additional toolkit projects.
One platform is "primary", web in our case. This is what developers mainly use to develop and test the app. We're using jsTestDriver for testing.
During the build, the app is packaged for web in the first step. We're producing several artifacts here (.war file, tests in a .jar file).
"Secondary" platform projects do not include the source code. It gets unpackaged and copied to the right places when projects are built. This also includes tests from the primary platform.
Platform projects contain some additional code - normally only testing code, app code itself is currently cross-platform (not sure if it will stay this way).
So we're doing it mainly through advanced build scripts. We're using Maven for web and Android. iOS is coming soon (into our work, I mean), so we'll be looking for some sensible build tool there too.
We're building our projects using Hudson continuous integration.
What I have to admit is that this whole environment (multi-project Maven builds, JSTD, multi-node Hudson) is a hell of a setup, took quite an effort to figure it out.