Appium1.2.0released

ついにAppium1.2.0がリリースされましたね!!
XPathの文字化け対応が入るバージョンだったので、なにげに待ちに待っていた。

あと、ふと見たらコードネームが1.2.0ではついていなかった・・・

XPath strategyの文字化けが修正されていて、ruby_libのfindが使えるようになっていた。

ruby_libのfindとは、

find(value)

にて指定したvalueを含む要素を取得する、というやつ。XPathの力のおかげで、単なるaccessibility_id strategyよりも変更に強いシナリオを記述できるようになるメソッド。
これで、例えば”あるボタンに表示される一部の文字が変数のように変化するが、他は変化しない”というような場合でも、その要素を取得可能な変更に強いスクリプトに落とし込むことができる。会社で部分的に修正を施して問題なく動作するようなら、社内に広めることができる状態になったと言えるかもしれない。(継続して開発する上で、やっぱり定型動作を機械が回してくれるのって、ありがたいのですよね)

Continue reading “Appium1.2.0released”

Bridging the Communication Gapを読んで1

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing [Kindle版]
を読み始めたばかりなのですが、少しずつメモをしようと思いまして。
※なので、題目としては読み始めて・・・のほうが良いかも?

この本、なぜか91%割引の日本円で千円以下で買えたのでお得感が結構ありました。

内容は、今からCapter1,2,3と読んでいく訳ですが、はじめのイントロダクションを読んだのでそこのメモを。

Continue reading “Bridging the Communication Gapを読んで1”

Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか

比較的、ぱっと見て操作を想像できることが受け入れ試験では大事だと思います。
そう考えると、RSpecはshared_exampleなんかで操作をまとめることができるのですが、Turnip/Cucumber形式のシナリオアウトラインを使った方が綺麗にかけそう。

一方、capybaraのように、RSpecの拡張としてFeature specを使うこともできる形があります。なら、Appiumを使って同様に受け入れ試験の形を模倣するならば、CapybaraのFeature specを参考に類似した記述を模倣すれば、RSpecのみである程度読みやすい受け入れ試験もかけるかもと思い、以下をまとめてみた。

Continue reading “Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか”

EveryDayRailsSpecを復習がてらやった、Cucumberは白痴?

https://leanpub.com/everydayrailsrspec
https://github.com/everydayrails/rspec_rails_4

これは、RailアプリをSpec含めてまるっと学ぶために良い知見を与えてくれます。
Code School もやってみようかな。

Continue reading “EveryDayRailsSpecを復習がてらやった、Cucumberは白痴?”

TurnipでScenario Outline

Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね
“Turnip or RSpec” x Appium
受け入れ試験レベルの抽象度のシナリオを、Appium x “RSpec or Turnip”で比較してみた
TurnipでAppiumを使ってみる

とAppiumとTurnipを使ってみたけれど、Turnipでscenario outlinesかけることが確認できたので、私の中でようやっとこの方向性が一段落しそう。
あとは、RSpecのshared_exampleの記述と少し比較してみて、という作業もいるけれど。

Continue reading “TurnipでScenario Outline”

FitNesseなどによるSpecification By Example

はじめに

LEANやAgile、BDDやATDDなどとあわせて、Specification by Exampleという、包括的な考え方が広まってきました。

これは、例によって振る舞い(仕様)を定めていく、という形のアプローチになりますが、そのときによく使われるツールが着想として面白い。

仕様としての例をWikiにより管理し、実装対象の例えばAPIに対してインプット、アウトプットを定義する。そしてそれを受け入れ試験の1つとして活用する。

これは、自然言語で例を与えながら仕様を明確にしていくことと、Wiki形式で表現することで理解しやすい形式にすること、開発物のインタフェースの検証のテストとして受け入れテストのインプット・アウトプットの検証にそのままWikiの記述が使われるところが有用です。

Continue reading “FitNesseなどによるSpecification By Example”

Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね

Genymotionの制御用引数がAppiumにプルリクされている所をみて、AppiumのOSSとしての成長加速時期がき始めているのかなと感じる最近です。Appium 0.17.3の次のリリースで含まれるのでしょうか。Androidの検証基盤としても本格的な立ち位置になりそう。

今日はStory Testでお世話になるであろうData / Keyword Driven Testingを少しおさらい。

Continue reading “Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね”

“Turnip or RSpec” x Appium

過去、こちらにて、AppiumにおけるテストシナリオをTurnipとRSpecのそれぞれの記述で比較してみました。
当時からまたいろいろ試し、考えてみた結果、ひとまずこうかな、という結論に達したのでメモがてら。

Continue reading ““Turnip or RSpec” x Appium”

Appiumの不安定なところいくつか

Appium 0.16.0 がリリースされましたね!

さて、iOS/Androidともに動作確認しているのですが、いくつか出くわした現段階の不具合を備忘録かねて共有です。

Continue reading “Appiumの不安定なところいくつか”

受け入れてテスト自動化に向けて

も少しいろいろ考えてみたけれど、受け入れテストを実際に書く場合、
1. Turnip部(.feature, .step)には主要ストーリ、変更の少ない箇所を記述する。featureの記述者の想定はユーザストーリーを描く人ら。
2. RSpec部で、より細かな確認事項を書く

とするのはどうかなと思い始めた。
というのも、保守観点を意識すると、RSpecのほうがエンジニアは保守しやすいのではないかなと。
私自身、RSpecのほうが気軽にかけましたし。

Continue reading “受け入れてテスト自動化に向けて”