Lately, I’ve been using composer to run instrumented tests in the Android world. ([Android]composer and swarmer)
Today, I just found an interesting PR. => https://github.com/gojuno/composer/pull/138
The PR is emulating the behaviour like AndroidTestOrchestrator. As you know, the orchestrator has some limitations and it includes
Parameterized tests aren't currently supported. It is JUnit4’s feature. So, the test support library has introduced JUnitParams.
The PR also has the same limitation. My project has been introduced the new
Params so we don’t affect the limitations. But if you’d like to introduce the new composer’s feature, you should take care it.
I also just found interesting news.
Espresso 3.0.2, Runner 1.0.2, Rules 1.0.2, Monitor 1.0.2, AndroidTestOrchestrator 1.0.2 (2018-04-24) have been released!
They have some good improvements and fixes. For example:
- Espresso 3.0.0 should NOT depend on test runner
- ActivityTestRule doesn’t update Activity instance during configuration changes
- Pass -e clearPackageData flag if you wish the orchestrator to run pm clear context.getPackageName() and pm clear targetContext.getPackageName() commands in between test invocations. Note, the context in the clear command is the App under test context.
Reading the release note, they fixed and improved many things for AndroidTestOrchestrator. That is brilliant.
I read Antifragile Systems and Teams. Entirely, this book is DevOps book, I thought. This book also short. So I just left some lines in this article and I’ll leave here.
Anyway, do you heard Antifragile? I hadn’t known the word before.
Let refer the Taleb’s word from a book.
“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better”
As the word said, antifragile is anti + fragile. But it isn’t not fragile. It’s more robust and resilient thing. And this book tried to show how to build such systems/teams, especially software development industry.
Lately, I believe DevOps methodology became common. We can imagen agile, flexible, robust and autonomous things. And this book also challenges to show use cases and examples for it.
What I surprised was I saw QA(Quality Assurance) related engineers often appeared. I thought this kind of books shows some ideal story, but this book was more close to real DevOps story. I also read DevOps and Testing books as same as this book.
This book is too short. Only 20 pages in PDF and they were summarised good enough things. So, if you have an opportunity to read it, let’s read it.
See you happy DevOps? 🙂
In general, we compare two images when we’d like to detect differences between them in visual.
I believe OpenCV and ImageMagick are famous tools to achieve the purpose lately. But sometimes we faced building errors, for example. So, I’ve used a simple enough comparison tool. That is Kobold. The library uses blink-diff as a comparison engine. The library provides some features to configure how to compare each other.
I’ve published Ruby wrapper to use them.
And you can also see some articles for it on this site. (Most of them are Japanese, and you need to translate though…) Link
By the way, I also researched some similar and straightforward libraries. I believe perceptualdiff also a famous library. I compared ImageMagick and perceptualdiff a bit before.
A few years ago, I started to investigate OpenCV, opencv_sample is one example, to make such comparison more flexible. The reason why I investigated it is many guys have been implemented Machine Learning / Deep Learning features in it. So I’ve believed it helps us.
And lately, Appium is going to support OpenCV based comparison features as one of the fundamental features. https://github.com/appium/appium-support/pull/65 is the brilliant PR. We can use some OpenCV features via them. We are also able to get diff images to ensure the results in visual.
The feature will help many users who would like to get image comparison easy.
Actually, to make test suites stable, separating steps are important like:
- Conduct test cases and assert the results without image comparison
- Compare images
- Collect and save the results
Otherwise, the new Appium feature will encourage automation more, I believe.
Note for me to get rid of local git branches.
git branch | egrep -v "(^\*|master)" | xargs git branch -D
Before Xcode 9.2, we can get formatted coverage data using https://github.com/SlatherOrg/slather, for example. The library formats
But from Xcode 9.3,
xccov is introduced officially. The command can run via
xccov is a new command-line utility for inspecting the contents of Xcode coverage reports. It can be used to view coverage data in both human-readable and machine parseable format. To learn more, enter man xccov in Terminal. (37172926)
I tried the feature with https://github.com/KazuCocoa/test.examples and I put a simple Ruby gem script to get the target name and the line coverage.
$ git clone https://github.com/KazuCocoa/test.examples && cd test.examples
$ xcodebuild -workspace test.examples.xcworkspace -scheme test.examples -derivedDataPath Build/ -destination 'platform=iOS Simulator,OS=11.3,name=iPhone 7' -enableCodeCoverage YES clean build test CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport > result.json
We can get some kind of format.
# Output: https://gist.github.com/KazuCocoa/40eaa3ac9de5e52c1a3795c49657dd4b
$ xcrun xccov view --json Build/Logs/Test/*.xccovreport | jq .
# Output: https://gist.github.com/KazuCocoa/879554e02934d368f976959d3f8cec4b
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport | jq .
Parse the JSON with Ruby
parsed = Xccov::Parse.new(file: './result.json')
parsed.targets_line_coverage["test.examples.app"] #=> 0.35
From Xcode 9.3, we can get formatted coverage data using
xcrun command. I’ve seen some scripts use Slather and Nokogiri to handle XML format and collect them. But the script will be more simple. Does this make you happy?
楕円曲線暗号(Elliptic Curve Cryptography)の話なんかもでてきて、大学のころにやったことも含まれて良い感じだった。主にはセキュリティ関係のところを想像しながら聞いていた。
I bought the book of Practical Network Automation when the book was discount.
The main topic is Ansible and Python code for network engineers who have few experience for Python/PowerShell. I expected more programming related stories, but it is a bit fundamental stuff.
BTW, when I saw some word such as “Software Defined Network”, “Open Flow”, etc, and it made me nostalgic… (My previous company and sort of my university age.)
So long ago, I tried to monitor iOS performances using instrument commands. But I gave up once because of host machine’s load.
But https://github.com/appium/appium-xcuitest-driver/pull/637 is created and that is awesome…
I just remember seeing the PR and I’ve published this article in my memory…
I know of Kubernetes, but I have few experience for that.
But the kubernetes community has interesting tutorials.
I can imagine the architecture and how to work.
I guess I’ll use them and Istio though.