はてなキーワード: jUnitとは
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは?って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
UT言うてもJUnitとか関係ないTシャツの話ね。UNIQLOがコラボして出してるTシャツ。
数年前までは、とても買いたくなるレベルではないしょうもないものばっかりだったけど、シン・ゴジラとか進撃の巨人のとかそこそこ有名タイトルとやっとコラボし始めてちょっと買ってみたのよ。
コラボ言うても安いから、質はあんまよくないんだろうなと思ってたけど、ビックリするぐらい良いね。ちゃんと単体で着れる厚みあるし肌触りも良いし。しまむらのやる気のない印刷しただけの安物Tシャツとは出来がちがう。
この点だけでもうユニクロ再評価したくなったね。ちょうどズボン無くなってきてたからセール品も買ったりして。買うことに余り抵抗が無くなってよかった。ズボンも見た目スーツっぽく見えるのも出してくれてるお陰で買うのにそこまでためらいがなくなったんだろうな。
なんとあの有名アニメーションのピングーのUTも出てる。ところがどっこい、サイズが赤ちゃん用。
大人用のはない。なんでだ?
Noot,Nootでも海外ネットユーザーに人気あるだろうから、そこらの有名シーンを持ってきてTシャツデザインに落とし込めばそこそこ売れるんじゃないっすか?
自分は今32歳だ。東京タラレバ娘の漫画の初刊だけ読んで、東京オリンピック開催時に32歳?うっそ信じられない、わかるわその怖さ、的な反応を確か2014年くらいにした記憶を今唐突に思い出したけど、その32歳になってしまった。けれども、三十路から眺める人生地図 - みんからきりまで を読んでいて、「完熟してしまったプラットフォームへの興味関心を失うこと」、「加齢によるパフォーマンスの衰え」、わかるわーめっちゃわかるわーってうなづきながら読んでしまった。違うといえば、30歳という具体的な峠を過ぎて全力で下り坂を転がっていることくらい。でもこれから失いつつあるであろうものへの恐れが依然として残ってるので、もうなんだろうねとしみったれた心でやりきれない毎日を過ごしている。
1月生まれの自分にとっては、4月はじまりではなく1月はじまりで一年を振り返る癖が社会人になってから自然と身についた。つまり自分の中では32歳の半年がすでに過ぎたわけだけれどもコロナで一人暮らし歴14年の子供部屋おじさん的には心の未熟さを痛感する次第だった。長引くリモート生活で、昼夜が完全に逆転して、朝11時からあった部会を完全に寝過ごしてお水エンジニアってあだ名を営業の人にいただいたり。それでさすがにやばいと思って完封したはずの個人輸入禁止前に大量に買い占めたデパス錠...正確にはゾピクロン錠か、を取り出して完全に依存症と化したり。薬の副作用でちょっとしたことで切れやすくなる自分をあ、今きれているのは明らかにおかしいと自覚しながらキレて、その後正気に戻っては眠れなくなることを繰り返してたった三か月前しか経ってない今はまだちょっと当時を振り返りたくない。ぶっちゃけ今でも週末の金曜など薬の影響が平日に及ぼさない日にいまだに飲んでるし、抜けられていない。
あ、そうだ、身体変化か。全て薬のせいなら良かったのだろうけど、薬抜いても何も変わらないね。集中力すぐに切れるね。30分が維持できないね。アスペの傾向だったのでむしろシングルタスクなら処理速度指標は高い自負があったのだけど、ここ数年は完全にアドバンテージを失ってしまった。いや、考えてみれば普通に第一志望大学を落ちたあの日以来、なにか本腰いれられたことってあったのかな。リングアウトアドベンチャーは高い抽選倍率をくぐり抜けて変えた反動で四天王が闇落ちするぐらいまでは毎日やったけど、ぷっつり飽きたぜ。
完熟されたプラットフォームといえば、自分も転職前はAndroidのアプリケーションもLinuxKernelもちょっとやっていたから成長中の楽しさはすごくわかる。kotlinはぶっちゃけほとんど覚えれなかったへぼいプログラマーの戯言だけど、Dagger2の登場でまるっきりプロジェクト構成が変わってしまったアプリケーションの構成はおおおおおおおおすげーーーーー!!jUnitってこうやって使うんやーーー!!t_wadaさんのセリフがやっとわかったぜー!!!って感動があったものだ。PFレベルで言えば、AndroidOS4.3から6.0くらいがめっさ楽しかった気がする。昔話しかできなくてごめんなさい。でも、AndroidOS4.3のBLE対応で知ったIoTの世界、AndroidOS4.4のKならkuzumochiやろと勝手に思ってたらkitkatって名前に決まって失望しちゃったけどOSとしては意外と悪くなかったこと、AndroidOS5.0のバージョンごと抹消されるレベルの混乱、5.1は覚えてないけど、AndroidOS6.0でWiFiのSSIDがbackendで取れなくなって代わりの手段を探すことになったりセキュリティ基準の変更に色々戸惑ったこと、バージョン更新ごとにいろんな出会いがあり、お祭りがあった。客先常駐だけど、品川とか武蔵小杉とか日本でAndroidの開発拠点があった場所にいさせてもらって色々楽しかった。まー、自分は増田ほど人ができてないから当時知り合った人たちで今も交流がある人はそういえばまったくいないけど。人脈とか友情とかそっち方面の資産はまったくできなかったな。変わっていくプラットフォームは楽しかった。
去年出会ったKubernetes=k8sもそう。一時期RSS等でKubernetesの情報がないか人力クロールを何度も繰り返すレベルだったけど、かといってrepositoryにPR送れたこともdoc系ぐらい?かかわりも薄いまま、いつのまにか今のバージョンからサポート期間が一年に延びたというではないか。Sidecar周りの整理だとかまだ課題はいくつか残っているけど、SIGによっては今後の機能拡張ネタは明確に決まってないところもあるし、あーもう成熟しつつあるんだなって当時の熱情を失いつつある。rustが来ると聞いて、k8sつながりでrust-vmmとか追ってみたけど、mailinglistのData量的に明らかに去年がピークだった。多分勢いを失いつつあると思う。これfirecracker以外に来るのか?rust/wasmはYewがあるし、Envoyのpluginもあるし、フロントエンド、バックエンドサービスとしては今後に期待だけれども、kernelに対しての適用、driver周りから浸透する未来はちょい疑義的。とりあえず、Kubernetesという超巨大プロジェクトを突き詰められた感じもしないまま、多分EKSしか触れない今、オンプレ系の構築、運用技術はKubernetes the hard wayの第四章のオレオレ証明書取得処理がコマンド打つだけなのに辛かったという記憶を残して風化するんだろうな、あと一年ぐらいで。そんな予感がある。
改めて人との縁が残っているこの人がうらやましい。ヒューマンスキルが元から皆無な自分にはわからないけど、漏れ聞こえた話だと新人とまじ会話繋がらなかったという話もあるし、10歳差を超えた会話はスキルじゃなくてもう才能でしょレベルなので結局同時間、同時代を一緒に生きた同年代の人たちをかかわりをどれだけ残すかなんだと思う。新しい縁ができなくてもそれは衰えじゃなくて自然なのだろう。過去十年を振り返るなら、自分はその維持をまったくしてこなかった。だからこれからはお金で買おうと思う。多分後十年くらいして月1~2万円所得を上げられたら、バーチャル嬢に昇給した所得を全部突っ込んで、桜蘭高校ホスト部の環x鏡夜編がいかに良かったかもうずっとその話ばかりする予定だ。それだけを生きがいに生きていく予定だ。カビが生えたレベルのjavaスタックとk8sとrust、その辺でエンジニアとしてうだつの上がらない生活を送りながら。
システム開発は色々面倒な作業がつきまとうが、特にテストがしんどい。
設計のフロー1個1個にテストケースを作ると、それだけで1メソッドあたりのケース数が30くらいになってしまう。
何よりケースを抽出し、文章にするのはどうやっても効率化できない。
それだけならまだいい。
基本コピペであっても記述量が膨大で、書いても書いても終わらない。
そんなことを要求してくるJUnitは最低最悪のツールだと思う。
大体、テストコードで開発が効率化されるとか、寝言抜かすなと思う。
そして以上の作業を1メソッドにつき1週間でやるとか、遅筆の自分には無理。
そもそもフローで書かれた手続きをJavaで実装しようとすると、処理のネストは深く、かつ記述量も長くなってしまって非効率この上ない。
大きな開発でJava使う意味なんて、というかオブジェクト指向を持ち出す意味なんて殆ど無いどころか、書きにくくなるばかりで、これまた開発の効率化なんて嘘だと思う。
あまりコミニュケーションが得意ではないのもあって、入社直後は非常に苦労した。
正直人見知りだったのでわけのわからないことをのたまっていた時期もあった。
とはいえもう4年目であり色々と手馴れてきて精神的にも余裕ができてきた。
しかも、最近の現場は9時-5時で帰宅できるようになり肉体的にも余裕がでてきた。
と、ここらでレベルアップを図りたいと思っており色んな設計書の問題点を指摘した記事とかを読み漁ってきたわけだが
アジャイルだの詳細設計書がゴミだのいろいろ指摘しているのは見かけるのだが今の自分の現場と環境があまりにも違いすぎてピンとこないのだ。
なんせ、入社してからやったのがガチガチのウォータフォール型の開発でアジャイルだのなんだのをまったくやったこともないからだ。
Gitなんて使ったこともないし、eclipseでSVNでソースを管理し、古いシステムならCVSだって未だに現役がちがちだ。
幸いにもドキュメントはがっちり作ってあって過去のシステムがどういうものなのかはよくわかるようになっているが。
もちろん転職しちゃえとか色々まぁ考えようはあるが別に今の会社に大きく不満があるというわけではない。
そこでSE経験の長いお歴々に色々尋ねたいことがある。
http://nantonaku-shiawase.hatenablog.com/entry/2014/05/18/012107
↑上記のサイトでウォーターフォール型開発の例を逐一説明してくれているがこんな一文がある。
ネットで検索すると、みんなが批判している。私も作ったことがない。というか時代遅れと言われがちなSIerの私ですら書いたことが無いのに、書かせる企業 is 何。
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
詳細設計書に何を書くべきか? - Sacrificed & Exploited
EXCEL設計書 Vol.1 怪文書大公開 | Same Old Lucky Day
詳しすぎる詳細設計書 - SiroKuro Page
ネットで検索すると、みんなが批判している。私も作ったことがない。
俺は入社してからずっとガチガチに詳細設計書を書いていたし、先輩も皆書いてる。
一体どこの世界の話なんだ。
いくつかの現場にも出向したがそこでも普通に詳細設計書を書いていたぞ?
どういうことなんだこれは。
でもよくよく考えたら、なんだか説明されている詳細設計書と機能設計書は俺が書いている「詳細設計書」ではひとつにまとまっている気がする。
そもそもそんなのないかも知れないが。
そこで尋ねたいのは事例として機能設計書や詳細設計書の具体例が欲しい。
書籍でもWEBページでもなんでもいい。
そうじゃないとなんだかそもそも話に付いていけない。
あと、詳細設計書がかけなくなりそうだ(切実)。
ところが俺の住んでいるところではExcelにテスト項目を俺が書いて俺が単体テストを手動でやって、結合テストも俺が手やる。
結果列に○だの×だの書いて失敗したらまたやり直しだ!
延々とこれを繰り返す。
別にそれがいやだといってるわけじゃなくて(嫌だけど)、皆テストとかどうやってんの。
テストとかそもそもやってんの?
アジャイルだの何だのに手を出すのもいいのかもしれないがそもそもウォータフォールなV字モデルをぜんぜん理解し切れてない。
誰か教えてくれ。
ビールを飲みながらふと振り返って見ると、
いろいろと思うところがあり面白かったので、
酔いながらまとめてみる。
前職のSIerは技術力には自身があるらしく、技術力は負けません。と誰かが言っていた。
構成管理は「日付付きフォルダ」。javaのデプロイは、人の手でDB等接続先情報の構成情報を変更後、Eclipseからwarを生成。人の手でGUIからデプロイ。
実装(ひどければ設計も)海外へアウトソース。結果、java知ってますって人が「PermGen space?Xmxを上げとけ!」「Xmxはとりあえず、1.5Gで!」とドヤ顔とか。。
テストは、もちろん担当者が画面エビデンスを取りながらテスト。(もちろん、エビデンスやテストはリリースの時、確認の意味で使うだけ。)
障害時には基本、関係各所集まって、会議。。。プロパティファイルの差し替えだけで終わるのですが。。。。
ITを活用して、売上、利益を上げてきた。(もちろん、それだけじゃないけど)
構成管理はもちろんバージョン管理ソフト。ビルド、デプロイ作業はコマンドラインで一発。(ただし本番デプロイは一部人の確認作業あり)
実装も、内部で実施。テストはjunitで記述、一日に一度の自動テストと結果レポートが届く。
IT系システムの要件の優先順位の決定権は基本情報部門が持つ。(ただし戦略的に無理な場合あり)
自動テストと、皆が内部実装や仕様を強く知っているからか、自信をもって高速に機能を追加できている。
何より、自分でサービスを作っているからか、活き活きと仕事している。
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの?
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸?
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
うーん、そこは JUnit の使い方でなんとでもなる。
1つのテストケース動かす度にテーブル作り直すとかありえないし。
テーブルは作り直さずとも、テーブルの中身を truncate でひっくり返して、事前データをブチ込み直すくらいならば平気。
某銀行系での例。マジ怒られそうだから、若干ボカして書くけど、
ひとつのテストメソッド TestXxxDAO.testRetrieveFooBar() は、XxxDAO.retrieveFooBar() メソッドについての複数のパターンのテストを全てやる事にする。そのテストメソッドの中で
というサイクルを繰り返す。テストデータや想定結果は、全て OpenOffice calc なんかを使って、視覚的に書いておく。その ods ファイルを読み、DB に突っ込み、想定結果と比較する処理は独自フレームワークとして用意。ods ファイルは、「こういうデータを準備して、こういう引数でメソッドを呼ぶと、こういう結果になりました」というテストのエビデンスにもなる。
insert 後に select とかってのが切り離して考えられない処理ならば、それはそういう 1 単位の挙動だ。俺なら例えば、XxxDAO.insertFoo()、XxxDAO.retrieveBar() を作ってテストした上で、そいつらを XxxLogic.doSomething() に押し込むね。そしてやはり上記のようなテストが出来る。
頭の中だけだと「それって現実的じゃなくね?」と思えるかも知れないけど、実際やってみるといい。テスト順なんか気にせずにやっつけてしまえるし、案外これで効率よく厳密なテストが出来る。それでもヘタクソな野郎は、テスト順に依存したテストを作りやがって、後でメンテする俺涙目みたいな事にもなるけど。
これでテストデータを作るのが死にそうなほど大変であれば、メソッドの粒度を見直すべきかも知れない、というセンサーにもなる。・・もっとも、XxxLogic.doSomething() などを処理順に纏めた XxxAction.action() なんかのテストともなれば、やっぱ大変なんだけども。
でも、テストって普通、簡単なものから難しいものへ、順番に書いてくんじゃないの? そうなってないと品質上げていきにくいし。テスト順を不定 (ってこと) にして何がうれしいんだろ。
あるいはたとえばデータベースまわりのテスト書いてると、普通は副作用に依存したいと思うんですけど。1つのテストケース動かす度にテーブル作り直すとかありえないし。
INSERT のテストケースを動かして、次に SELECT のテストケースで読めるか確かめるとか普通やるよね。
てか、INSERT が動かないことには SELECT のテストが動くわけないのに。テスト順がないから、そういう依存関係の定義も面倒。
テスト順が明示的であれば、最初に問題が出たテストから順番につぶしていけばいいよね、ってことになるけど、順序が不定だから直感的じゃない。
つらいので愚痴らせて欲しい。
愚痴ればたぶん元気になるらさ。。。
毎日毎日残業。この半年間、
平日は1日に5時間も寝れない生活をしている。
自分は毎日定時に帰るくせに。
残業しましたが、何か???
ぼくは技術とか物作りとかをほざく、大手IT企業に入社して1年になる。
ものづくりねえ、でも実際はこの現状。プロジェクトマネジメントと
称して下請けをいじめるだけ。自分のミスを、下請けに無理言ってやらせるだけ。
ねえ、会社の先輩さ。普段偉そうにして下請けに威張っているけどさ、
あなた、自分一人じゃHello worldも作れないよね?
今日も下請けからJUnitも知らないって小馬鹿にされていたけど、
会社をなくして、あなた一人だけになったとき何が出来るのさ?
よくわからない数式とか振り回して、
もっともらしいこと言って「分析」とか称したってさ、
それが技術なの???
本当にそれが技術なの?