Fluentlenium導入した話
どうも、きくかわさんです。
ギョームでE2Eのテストを勝手に入れたかったので、唯一使用した事のあるFluentleniumを久々に使おうと思ったのだけど導入に5時間くらいかかった。。。
ちょっともうハマりたくない&他の人にはまって欲しくないのでメモ書き程度に収めてみる。
※注意 : 2017/8/28 時点での記事です。今後導入に取り込む場合はブラウザやドライバーのVersionに十分お気をつけください。
Fluentleniumの公式ドキュメント通りでは動きませんでしたので、公式とは差異があります。
fluentlenium.org
まず、GeckoDriverの最新を取得しておいてください。
Mac用とか、Windows用とかあるので注意。(書いてるけど)
2017/8/28日時点では、v0.18.0を使用しました。
github.com
今回使用したブラウザとVersion
・Firefox version: 55.0.3
build.gradle
group 'kiku' version '1.0-SNAPSHOT' apply plugin: 'java' apply plugin: 'idea' sourceCompatibility = 1.8 repositories { mavenCentral() } dependencies { testCompile 'junit:junit:4.12' // 以下2017/8/28 時点の最新を使用してます testCompile 'org.fluentlenium:fluentlenium-junit:3.3.0' testCompile 'org.fluentlenium:fluentlenium-assertj:3.3.0' testCompile 'org.seleniumhq.selenium:htmlunit-driver:2.27' testCompile 'xml-apis:xml-apis:2.0.2' testCompile 'org.seleniumhq.selenium:selenium-firefox-driver:3.5.2' }
MyFluentTest.java
mport org.fluentlenium.adapter.junit.FluentTest; import org.junit.Test; import static org.assertj.core.api.Assertions.assertThat; public class MyFluentTest extends FluentTest { @Override public String getWebDriver() { // システムのプロパティに、先ほど取得したgeckodriverを設定 System.setProperty("webdriver.gecko.driver", "src/test/resources/exe/geckodriver"); return "firefox"; } @Test public void GoogleでFluentLeniumを検索した時のタイトルがFluentLeniumになること() { goTo("https://google.com"); $("#lst-ib").fill().with("FluentLenium"); $("input[name=btnK]").click(); assertThat(window().title()).contains("FluentLenium"); } }
一応ソース
github.com
あとがき
Versionが記載のものと全く同じであれば、これで動くかと思います。
ChromeやIEを使用する場合にも、FirefoxDriverのようにWebDriverがあるはず(IEについて未確認)なので、
それを指定すれば何とかなるかもしれない。
何かとエラーが出た時に、最新にあげると治るよーって書いてたのでそれに従えば何とかなった気はする。
ただエラーログと格闘することになるので、英語に強くなりましょう。(ググってもほぼ英語)
しかし、Fluentlenium1.x系を使用する際にFirefoxの設定はデフォルトなのでいらなかったはずなのに、
なぜかいるようになってるのが、どこからかのFluentleniumのVersionが上がった時に変わったのかな?
今回、GeckoDriverっていうのも初めて知った。
でも多分、FluentleniumはSeleniumのラッパーライブラリなので、SeleniumのVersionが上がった時か。(そこらへん詳しい人教えてください)
※追記(2017/8/30)
Seleniumが3になったとき。
— irof () { ... } (@irof) 2017年8月30日
詳しい人が教えてくれました。@irofさんありがとうございます。
GitIssueとStackOverFlowにはすごく助けられた。
あと、ある人にも。
意味のある名前について
Clean Codeを題材に色々書いた。飛ばしている目次もある。
自分にとって必要なところだけ写経。自分の思いが強いところは自分の言葉で。
■意図が明確な名前にする
その意図が明確な名前をつける、言葉なら簡単に言える。
胸に刻みつけることはたくさんあるが、良い名前をつけることはその後の時間の節約できる。
名前をつける時は注意深く、そして後でより良い名前が浮かんだら変更してください。そうすることで他の人を幸せにできます。
変数、関数、クラス名は大命題に答える必要があります。なぜそれが存在するのか、何をするのか、どのように使用するのか。もし名前に説明が必要なら意図が明確とは言えません。
意図を表現した名前を用いれば、コードはもっと変更しやすいコードになります。いかに例を書いた。
public List<int[]> getTeam(){ List<int[]> list1 = new ArrayList<>(); for(int[] x : theList){ if(x[0] == 10){ list1.add(x); } return list1; } }
難しい記述はないものの、これではしたことが明確には分からない。というか伝わらない。
このコードを見た時、暗黙的に考えてしまうことが
1. theListはなに?
2. 4という値はなにを表すのか
3. 戻り値のlistはなにを指すか
4. theListの[0]はなんだ
上記のような暗黙の問いは、コード以外の場所に存在する。(ドキュメント類)
では、次のように書き換えてみよう。
マインスイーパーのプログラムだとした時、
public List<int[]> getFlaggedCells(){ List<int[]> flaggedCells = new ArrayList<>(); for(int[] cells : gameBoard){ if(cells[STATUS_VALUE] == FLAGGED){ flaggedCells.add(cell); } return flaggedCells; } }
コードの構造は変えずに、値に意味を与えた状態。さっきより読みやすい。だけど条件式などがまだ明確でない。次は、厳密に役割を与えて名前をつけてみよう。
public List<int[]> getFlaggedCells(){ List<int[]> flaggedCells = new ArrayList<>(); for(Cell cell : gameBoard){ if(cell.isFlagged()){ flaggedCells.add(cell); } return flaggedCells; } }
こんな感じで、名前を明確化し、適切な名前をつけるだけでコード上で何が行われているのかが読み取りやすくなります。
■偽情報を避ける
コードの情報を曖昧にしてしまうような、間違った情報をコードに入れるのは避けるべき。その単語の意味が確立されて意味が、我々が意図した意味以外に様々に存在するのであれば、その名前は避けるべき。複数の顧客際に、実際にそれがList でないなら、accountListという名前を使用するのはやめましょう。間違った理解を招く可能性があります。accountGroup、あるいはaccountsのような名前がいいと思う。似た概念に似た綴りを与えるのは1つの情報になります。ですが、ごく一部分のみが異なる名前をつけないように。XYZControllerクラスに、EfficientHandlingOfStringとEfficientStorageOfStringが混在していたら気づくのが遅くなる可能性があります。整合性のない綴りを使用するのは錯乱します。気をつけましょう。
■意味のある対比を行う
get1やget2のような、数字の連続を使用した名前は避けてください。クラスも同様です。これは錯乱というより、無情報です。これらの名前はプログラマの意図を提供しません。
public static void copyChars(char a1[], char a2[]){ for(int i = 0 i < a1.length; i++){ a2[i] = a[1]; }
このメソッドの引数の名前が、source、destinationなら読みやすくなりと思います。ノイズを発するワードにはまた別の無意味さがあります。例えば、Productというクラスがあるとして、ProductDataやProductInfoというクラスがある場合、違う名前をつけても意味は一緒です。InfoやDataは英語のa、an、theのようなものです。意味に明確な違いがあるのであれば、付け加えるのも間違いではないということも注意してください。読み手に違いがわかるような名前をつけてください。
ノイズワードは冗長的です。variableという単語が変数名に含まれてはいけません。tableという単語が表の名前に含まれてはいけません。NameStringのどこがNameよりも優れているというのか。
■発音可能な名前を使用する
オレオレ省略はやめてください。headerの事、getHdrはgetHeaderだとか、DtRcdはDataRecordだとか。例外もあります。例えば、indexはiと略されたり。
名前が長くなっても、オレオレ省略はやめてください。そもそも長くなりすぎる名前には、責務与えすぎという問題も気にしてください。
■メンタルマッピングを避ける
自分がつけた名前を、コードを読む人が心の中で(その人が知っている)名前に変換しなければならないような状況を作ってはいけない。ノイズになります。
■根拠のない文脈を与えない
例えばの話、プレフィックスやサフィックスを「整合性」としてつけるのはやめましょう。それはコードには関係ないので。ソレの役割を適切な名前で使用してください。
以上。
だいぶ要約して書いた。他の人と理解が違っている箇所もあると思うけど、そういう時は指摘してくれると助かります。
それにしても最後らへんの飽きた感w
けどいいや。
TDDBCで僕が持ち帰ったもの
どうも、きくかわさんです。
TDDBC(Test Driven Development Boot Camp)に参加してまいりました!
仕事以上に疲れた。俺いつも手抜いて仕事してたのか‥って思うくらいには。
・参加への理由
TDDってテスト駆動開発の事ね、はいはい。。。で?詳細は知らないよ?
ってなったので参加してみた。いつもそれっぽいことはしてるけれど、TDDについて説明できない =「つもり」を解消したかった。あとは、、、ペアプロ久しぶりにしたかったんです。はい。
・TDDBCの目標(あくまで個人的な見解)
今日のテーマは、気軽に!だった。
そして、TDDBCはこう謳ってます。
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
TDDを体得すること!!
つまり、2回目の受講者としての参加は、この人たちにとっては責務を果たせてないらしい。 きっとTAの人たちへの一番のお礼は、次TAとしての参加なんだろう。
・内容
最初に講演、TDDのこころ(タイトル忘れちゃった)をご静聴。irofさんのスライド、名言的なの多くてめっちゃすこ。(変な意味はないです。)
続いてデモペアプロをご騒聴。完全コントでした、これは褒め言葉です!コンビ名は左右らしいですよ。
あとはTDDペアプロで50分、振り返り10分を3回転。集中してたからかな、なかなかキツかった。
コードレビューして全体振り返りして、びあばっしゅ。
まぁ色々割愛。
・感じた事
TDDってこんなに難しいの?って。ペアプロも取り込んだから余計に難しく感じのかな。テーマは気軽に。ちなみに気軽の意味は
こだわったり面倒がったりしないで行動に出るさま。また、堅苦しくなくて、気がおけないさま。
気軽にはまだなれなかった。こだわるし、面倒だし、堅苦しい。でもTDDスキルを身につけることで解消できそう。むしろ思想?が好きだから今後とも寄り添っていきたいと思うよ。
あと、Clean code that work. (動作するきれいなコード)って言葉。
誰もが望む事だと思うけど、実現できる人はどれだけいるんだろう?ってそんな感じ。
・僕が今日TDDBCで得たもの
1. TDDのルール
- 重複を取り除く
- 新しいコードを書くのはテストが失敗してる時だけ
2.テストパターン出しの助けになること、要素、心がけ
- 不安をテストする
- ToDoリストを作成し、それをテストとする (最初に作りすぎるより、ある程度出して、他からのフィードバックを元に追加していく)
- 引き返す (テストをしていると、「あれも、これも」となる。そうなる前に、「一息ついて」「前に戻って」「小さなステップを意識する」)
3. TDDのサイクル
RED -> GREEN -> REFACTORINGのサイクルに乗っとって実装していく。それぞれのSTEPで気にすべきことがある。
RED
- Assert First (最初にassert書け。話はそれからだ。)
- Dog Fooding (自分が作った料理の味見してみ?ってことかな。)
- エラーを観察しょ。。。 (エラーログが自分に何を訴えているのか見定めよ)
GREED
- 仮実装 (なりふり構わずテストを通せ。話はそこかr)
- 三角測量 (すみません、これよくわからない。)
- 明白な実装 (一息でコードを書くが吉。実装方法が明白なら出来るでしょ?)
REFECTORING
- 容赦のないリファクタリング (コードの悪臭を感知して早期に取り除く。)
- テストのリファクタリング (テストも同じように、悪臭を放ちます。プロダクトコードをテストコードとして、テストコードをリファクタしましょう!)
- リファクタリングの止めどき (次のテストを通すために変更箇所が1箇所なら止めていい。)
簡単に説明すると
テストを書き、テストを通すためのそれなりのプロダクトコードを書き、通ったらプロダクトコードをきれいにする。これの繰り返し!
以上、今日の収穫です。 三角測量が本当わからない。。。
まぁできるできないは置いといて、チャレンジ精神と取り組みのルールはいただきました。ありがとう!
・あとがき
Developer Testing
開発者が開発者のために,
自分自身のために, もしくはチームメンバーのために行うテストです。
これもすこ。(横文字名言の好きさ加減がハンパない気がする)
不安を解消してくれる奴っぽいし、しもふりにく沢山与えて仲間にしたいよねー。
「つもり」は多少改善された「つもり」
これ堂々巡り!!
あ、TAの皆さん、会場貸してくれたFirst Serverさんありがとう!
届け、俺の感謝の気持ち。
関ジャバ主催のKANJAVAPARTYに行ってきた!
どうも、きくかわさんです。
内容が絞られるためタイトル詐欺です。(自首)
6月24日の関ジャバのKANJAVAPARTYに行ってまいりました。
大規模イベントということで、かなりの人数の方や内容の濃いセッションが各部屋にて行われていてかなり刺激を受けた。(刺激受けすぎて死ぬかと思った。。。)
昨日ブログ書こうと思ったんだけどね、体力なくて帰ってすぐ死んだよ。 懇親会もあったし、二次会も少しの時間だけど行ったので。(夢見たいな空間だった。)
んでまぁ色々見たんだけど、ハンパないほどめっちゃはかなりすごくとてもしょるけど、寺田さんのセッションが「これはやばい。この人かっこよすぎる」って感じた。
日本で 2 人目の Java Champion になりました https://t.co/wDNsQZpl6O pic.twitter.com/vOJJIUPvd3
— 寺田佳央@エバンジェリスト (@yoshioterada) 2016年7月7日
正直なところ、Javaエバンジェリストとかすごさもわかんないし、JavaCampionだからどうとか俺はまだわかんなかったからそういう視座では見てなかったんだよ。ただ立ち振る舞いやその姿を見てただかっこいい。んでその未来に生きる姿勢がすごく響いた。技巧的でありエモいセッション。俺この人に救われたよ。だから今回はこの人に注目して書く。一番思い入れ強かったし、うん。
まぁ俺のモチベーション云々は置いといて、セッション内容について。
ブログに残すとか考えてなかったし、主に自分が興味のあることしかメモってないから粗雑ではあるのでご了承を。
$$セッション題名
■You can change the world! AI & Bot でより良い社会を作ろう!
内容的には、「〜教えて」って入力したらURLとか、その説明がが返ってくるような感じのアプリを題材にしてた。UIがLINEみたいな対話形式だったのも。
その裏側を見せてくれたり。使ってたのがMicrosoftのAPI多かったし、RESTが使えればどの言語でも的なことをおっしゃってたので敷居を下げてくれたりね。
そもそも翻訳とかってGoogleとかIBMのワトソンのイメージもあってMicrosoftがそんなの作ってたのかおい。って思いましたまる。実際にコードとか見せてもらったり。凄く簡素だったイメージ、API呼ぶだけだからかな?
んで、今回それを作るにあたって一番時間かかったのが「データのパターン作る」ところ。…わかる、凄くわかるよ!!!って心の中で叫んだ。(心が叫びたがってたし)
そういう「〜教えて」って言い方が一つならいいんだけど、方言もあるし言い方が変わっても意味が同じなんだってのを、自分でパターン出す時って限界あるししんどかった、って経験があるから物すごく共感できた。それとこんなにすごい人と同じところで苦労したってとこがなんか嬉しかった。
最後にほんやくコンニャク、はい。これ聞いた時、アァスゲーミライってね。本当に未来的だった。リアルタイム翻訳のことね。
まぁ理論的にはデバイスから音声が取り込まれてそれをテキストに置き換えて翻訳して音声データにして返す。
これができればいいんだけど、なんかそれを見た時すごいなぁって少年の心取り戻した。(小学生の夢がゲームプログラマだったのも思い出した。)
$$気になった単語
■Cognitive Services
まぁMicrosoft のインテリジェンスAPIの集合体なのかな?
■Microsoft Translator
まぁ、翻訳サービスだね。
Cognitive Servicesの一つにもそんなのがあったけど違いってなんなのかな?
Microsoft Translator - Built for enterprise
(これだけ埋め込みできなかった。)
■LUIS
自然言語を解析してくれるツール。文章の種類を振り分けたり、キーワードを抽出してくれるやつ。GUIでできるんだって。
他にもあったんだけどさ、これらが気になってて。
(仕事でもこんな感じのことしてるし)
特にLUIS。本当これみたとき衝撃受けたんだよね。
これを知るまでは、入力された文章を自分で形態素解析して、XMLで管理しておいたフレーズに対して類似するフレーズにパーセンテージ降って、一番スコアが高いフレーズを叩き出して、それに関する処理を行って。。。ほんと泥臭いやり方してるw
これを知っただけでも、あの場に行った意味も出てくるし「勉強会ってか、予習会なんじゃねぇか、、?」という思いが強くなった。
まだ使えてないんだけど、このブログではとりあえず「思いの丈を書く」と決めていたのでLUIS使った軽いアプリ作れたらまた何か書こうと思う。
最後に。
他にも面白いセッションたくさんあったし、すごくためになった。
知識だけの話じゃなくて。耳の痛い話も聞いたし。笑
あとね寺田さんに「ブログ書くまでが勉強会」と教わりました。これからそうします、アウトプット大事だよね、登壇者が一番勉強になるって俺も知ってるし。
関わってくれたみなさんありがとうございます!(直接言えよ。)
悶々と
最近、悶々としてます。
ただの愚痴です。
いろいろあるけど、
・チームといいつつ個人プレイなチーム()
・朝の進捗を声かけないとやらない
・最新技術を使える案件なのに何かと古い
・ソースのテストを全くしない
・一部してる!って見つけたら結果をコンソールに表示してただけ…(assert使おうよ)
開発手法、手段ともにボロボロです(´∀`=)
技術力もないチームなので何だかこのままじゃ自分もダメになりそうだなぁとか思いながら最近は勉強を始めました。(4年目にして真面目になりだす)
どうにかしないと、、、と思ってチームの皆さんに直接投げかけたりメールを入れたりするも全く響かず、白旗をあげました。
このチームをどうにかするより自分がダメにならないようにするのに必死だ_| ̄|○
多くの人は現在まで培った経験や技術を武器に戦ってます。それで実現できることを知ってるのです。だから余計に辛い。
新しいものを更に取り入れるには学習や新たに経験を積まないといけない、効率よくするための何がしかをそれらによって効率が悪いと跳ね除けてしまいます。
ましてや若造にゴチャゴチャ言われるとウザいに決まってますよね(´∀`=)
だから分かり合えないと今は諦めて、もしまた気分が向いたらゴチャゴチャ言ってみようと思いましたまる
でも、なにをどう頑張ればいいのかねぇ…。
以上。