[過去ログ]
C#, C♯, C#相談室 Part95 (1002レス)
C#, C♯, C#相談室 Part95 http://mevius.5ch.net/test/read.cgi/tech/1508168482/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
854: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 00:04:24 ID:afVseoTo0 >>845 それがすんなり行くかどうかはアプリの作りによる。 例えば、VSのコンパイル機能は csc.exe へのフロントエンドでしか無く、コマンドラインオプションを作るだけの物ではあるだろ。 こういう場合は至って簡単で、そのまま吐くだけで済む。 上手く行かなかったとしたら、前回の内部状態と混線したのだろうけど、ぱっとは思いつかないね。 普通にアプリを作ってしまえば当然再現性はあり、 どのボタンを押したかをそのまま記録/再生すれば当然同じ結果は生成される。 それらを「人間が見て分かるそれなりのコマンド名」に落とし込むのは大変だろうけど、ぶっちゃけ、 CONTROL Button インスタンス名 Click 程度のDSLならその心配もない。 これ以上に格好良くしようとすると、色々大変なのは分かるが、正直、この程度でもDSLとしては十分だから問題はない。 (ちなみに一応言っておくと、Buttonのみならず、他全て、例えばradioButtonやNumericUpDown、TextBox等、 内部状態を変更するGUIコンポーネントについては全てこの方式で記録/再生してる。 そりゃ再生出来るに決まってるだろ、というのは分かると思う) http://mevius.5ch.net/test/read.cgi/tech/1508168482/854
866: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 19:45:45 ID:afVseoTo0 >>855 まあ君がどうしてもPowerShell推しなのはわかった。 > UI操作するオレオレDSLなんてまあバグだらけだろうな それはオレオレDSLに無理に高度な機能を持たせすぎてるから。 つるんと書かれたDSLをただ上から順番に実行するだけ、しかもエミュレーションの時に、 何行のコードを追加し、何行の既存コードを変更する必要があると思ってるんだ? 面倒だから答えを言ってしまうが、追加が30-50行程度、既存変更は0行、つまり変更無しだ。 エミュレーションが開発的に強烈なのはこの、完全に外付け出来る点だ。 >>849,850の争点もここで、俺は849と思想が同じく、「そもそもテスト項目を増やすな」でしかない。 だからバグっててもDSLモジュール内で閉じてて精々DSL機能が使えなくなるだけで、 追加テストはエミュレーション部分のみ、というのは十分魅力的なんだよ。 そして君はAPIAPI言っているけど、PowerShellには特にAPIを用意する必要があるわけではないだろ。 publicにしてある関数を勝手に呼ぶだけ、精々ドキュメントを整備するくらいだ。 当然リフレクションを使えば内部関数等は全部抜けるので、呼ぶだけならいくらでも出来る。 リバースコンパイラを使えば分かるが、リフレクションでも割と読めるコードが得られる。 後は好きなだけハッキングしろ、でしかない。(これを、そそる、と言っている) http://mevius.5ch.net/test/read.cgi/tech/1508168482/866
867: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 19:46:35 ID:afVseoTo0 あと、PowerShellにこだわりすぎて、強力なDSLなんてPowerShellでしか得られないと思ってないか? 気づいていないんだろうけど、「テキストファイルで操作する」というのはUnixのAPIであって、 そこに揃えるだけでUnix周りのツールが全て使えるようになるんだよ。 具体的に言うと、DSLソースをファイルではなく標準入力とすれば、 (一応言っておくがC#等GUIアプリもコマンドラインから起動すれば普通にパイプできる) その前段のツールが標準出力に「CONTROL Button instancename Click」と吐きさえすれば自動化できるのだから、 PowerShellみたいな糞文法につき合う必要もなく、言語も選べる。当然、C#やPythonも使える。 これも一応具体的に言っておくと python myscript.py | my.NETapp.exe な。 だから高級なDSLが欲しいにしても、フルスペックのDSLを自前で持つ必要なんてまるでなくて、 自アプリ内はアホみたいに「食わされたコマンドを処理して終わり」なDSL実行部分だけで十分なんだよ。 それで後はAWK/Perl/Python/Ruby等、好きな言語使って勝手にやってくれ、になる。 つまり30-50行程度追加し、既存部分にバグが発生することもなく、 AWK/Perl/Python/Ruby等好きな言語を使って自動化出来るのがエミュレーションの利点であり、 Unixインタフェースに揃える美味さだ。だからみんなここから離れられない。 http://mevius.5ch.net/test/read.cgi/tech/1508168482/867
868: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 19:47:56 ID:afVseoTo0 >>860 一応調べてみたが、この場合は微妙だし、どっちでも良いと思う。 > https://hinative.com/ja/questions/11390949 > https://xcelgo.com/emulation-vs-simulation/ 要は、中身まで模倣するのがemulationで、外面だけ合わせるのがsimulation。 よって実行速度は通常simulator>>>emulatorになる。 void Button_Clicked(Object^ sender, EventArgs^ e) { some_func(); } で some_func を直接呼ぶならsimulation、 Button_Clicked を呼んでもまあsimulation、 OnClick や PerformClick を呼ぶならemulation、というのが俺の見解。 emulation扱いの2つはClickイベントを発生させる=UIスレッドのイベントキューに積むだけであり、 ハードウェアマウスのイベントと見分けが付かないから。 (内部的にハードウェアマウスのクリックを模倣している) 対して上記simulation扱いの2つは、 simulatorが「このボタンをクリックしたら結果的にこの関数を実行する」と知っていて、 外面動作を合わせる為にそこを呼んでいる。 当然emulationの実行速度はsimulationと比べて遅い。 だから、最初からsome_func()呼べよ、という若さは分かるが、そこをケチっても実質的意味はない。 ここら辺は年を取れば老獪になるというか、手の抜きどころが分かるようになる。 emulation方式だと当然、UIスレッドがハングアップしていたら永久に処理されないし、 未処理のイベントがあればその後に処理されることになる。 ここら辺は完全にハードウェアマウスの動作と同じになる。 simulation方式だと、すぐに呼ばれる為、 非UIスレッドでDSLを処理した場合、未処理のUIイベントがあると処理順序が逆転してしまう。 だから、DSL実行環境とGUIの実行環境が同一の場合はDSL処理はUIスレッドでやるしかない。 だったら最初からPerformClickでやればそういう心配すらないだろ、ということになる。 http://mevius.5ch.net/test/read.cgi/tech/1508168482/868
869: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 19:49:07 ID:afVseoTo0 余談だが>>850のUIテストが安定しないのはこの辺が大きい。 要は、GUIなんて所詮人間相手前提で組んであるのであって、 CPUの速度でイベントを積まれた場合にも正しく動くレベルまでのテストは為されていない事も多い。 技術的に見ればアプリが糞で組み方が悪いだけだが、そこまで保証する意味もないのも事実。 結果、「人間がやると動くが、CPUでやると動かない」なんてのは割とよく遭遇することになる。 だからまあ、「UIテストは安定しないから出来るだけ回避」も一つの戦術だが、 「UIテストも安定するようにちゃんと設計する」も一つの戦術なんだけどね。 「安定しない」のはあんまり正当化していい話でもないし、 ちゃんと設計されているアプリしか触ったことのない人にとってはポカーンな話でもあるとは思うよ。 ちなみに、文句を言っている連中に合わせるとしたら、以下のようなDSLにすればいい。 CONTROL Button instancename Click // PerformClickを呼ぶ some_func() // some_func()を直接呼ぶ これで、好きな方使えで済む話で、実際も、これに近い。 (当然だがDSL用のコマンドは別に持ってて、全部大文字なのはそれらと被らない為の方策) http://mevius.5ch.net/test/read.cgi/tech/1508168482/869
873: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 20:24:09 ID:afVseoTo0 >>860 >>868訂正、結果的に>>869は間違いなのでよろしく 俺の見解では全部simulationになる。 確認してみたら、PerformClickは同期イベントだった。 呼び出し履歴見る限り、Button.PerformClick->Button.Onclick->Control.OnClick->イベントハンドラ なので、 OnClickもほぼ確実に同期だと思われる。 だから呼称は全て simulation の方が妥当となる。 イベントキューとかは全く関係なくなるので、該当部分の869の話は間違いということでよろしく。 同期イベントなのは.NETの癌だと思っていたが、 この点に関しては同期イベントの方がプログラミングしやすい、というのは事実だな。 (俺の想定の非同期イベントだと俺のコードは動かないはずなのに気づき、確認したところ、同期だったorz) http://mevius.5ch.net/test/read.cgi/tech/1508168482/873
874: デフォルトの名無しさん (ワッチョイ 477b-yNzz) [sage] 2020/02/17(月) 20:40:15 ID:afVseoTo0 >>871 > 論点をずらそうとしてるね お前がだろ。 > UI操作でオートメーションサポートするというバカバカしい発想の方な GUIの自動化ならGUIのエミュレーションが俺的に第一選択肢だ。 これについては既に>>842で言ったとおり、君が気に入らないのはどうぞご自由にだが、 最近話題のSeleniumでも同様なのだから、君が思うほど糞でもないんだよ。 もっとも汎用的で、もっともカッコ悪いが、どんな馬鹿でも使えるソリューションだ。 そして、やる気になればPerlやPythonと組み合わせて自由自在でもある。 ソースコード戦略にも、テストにも問題がない。ならこれで決まりでいい。 http://mevius.5ch.net/test/read.cgi/tech/1508168482/874
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.034s