Hokkaido.pm #11

3,784 views

Published on

Slides for Hokkaido.pm #11.

Talking about software testing and documentation.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,784
On SlideShare
0
From Embeds
0
Number of Embeds
2,992
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hokkaido.pm #11

  1. 1. Hokkaido.pm 🍣x11 ブログ炎上 @moznion from Hachioji.pm
  2. 2. @moznion 大学院生 (退学失敗) ソフトウェアエンジニア (アルバイト)
  3. 3. 今年の流行語
  4. 4. ではなくて
  5. 5. DevOps
  6. 6. Dev🔫Ops or Ops🔫Dev
  7. 7. Dev🔫Ops or Ops🔫Dev
  8. 8. Dev🔫Ops or Ops🔫Dev Dev💕Ops Dev🍣Ops Dev🍺Ops
  9. 9. DevとOpsが協調
  10. 10. めでたい!
  11. 11. 他に協調出来そうな 概念は無いだろうか
  12. 12. 例えば TestとDocumentの関係
  13. 13. Testとは?
  14. 14. ソフトウェアの正しい動作を 記述・表現・保証するもの
  15. 15. Documentとは?
  16. 16. 正しいソフトウェアの 動作を定義・表現するもの
  17. 17. つまりTestもDocumentも ソフトウェアの正しい動作に 着目している
  18. 18. DocumentとTestは 距離が近い
  19. 19. 協調可能ではないか?
  20. 20. 協調することによる メリット
  21. 21. Documentの 不整合を防げる 破滅しない
  22. 22. Documentの 陳腐化からの卒業
  23. 23. DocumentとTestを それぞれ書くよりも コストを減らせる(かも)
  24. 24. アプローチ
  25. 25. 1
  26. 26. Documentから Testを生成する
  27. 27. 2
  28. 28. Testから Documentを生成する
  29. 29. 第Ⅰ部
  30. 30. Documentから Testを生成する
  31. 31. Documentがそのまま Testと化すので 陳腐化を防げる
  32. 32. Documentを書く作業と Testを書く作業が 分離しない
  33. 33. しかし
  34. 34. 難しい
  35. 35. 実現しようとすると Documentが 冗長になる傾向
  36. 36. e.g. javadoc
  37. 37. Documentを書く コストが格段に 跳ね上がる
  38. 38. そのコストはDocumentとTest それぞれ分離して書いた時の コストと比較してどちらが高い?
  39. 39. また, Documentから 生成するテストケースは 適切だろうか?
  40. 40. etc etc…
  41. 41. 多分, Documentから Testを生成するのは あまり良い方法ではない
  42. 42. では生成するのを やめてはどうか
  43. 43. DocumentとTestを 同居させるという手法
  44. 44. e.g. DocTest (Python) Test::Inline (Perl) power-doctest (JS)
  45. 45. 今回書いたやつ
  46. 46. Test::Synopsis::Expectation https://metacpan.org/release/Test-Synopsis-Expectation https://github.com/moznion/Test-Synopsis-Expectation
  47. 47. CPANモジュールの Documentの中でも 非常に重要なSYNOPSIS
  48. 48. そのSYNOPSISを Testする
  49. 49. SS
  50. 50. SYNOPSISの中に テストケースを 同居させる
  51. 51. 可読性もそこそこ高いので 人間が読んでも理解できる
  52. 52. もちろんDocumentも 陳腐化しない
  53. 53. Documentを書くと Testも増えるという思想
  54. 54. 割と良いのではないか
  55. 55. Documentから Testを生成する DocumentとTestを 同居させる
  56. 56. 第Ⅰ部完
  57. 57. 第Ⅱ部
  58. 58. Testから Documentを生成する
  59. 59. r7kamura氏のautodoc
  60. 60. 衝撃!!!
  61. 61. autodoc?
  62. 62. JSON APIのTestを書くと APIのDocumentが 生成されるやつ
  63. 63. Testで動作が正しいことが 保証されているものが そのままDocumentになる
  64. 64. 正しいドキュメントが 必然的に得られる
  65. 65. APIとか代謝が早くて Documentが追いつかない ケースが多い
  66. 66. ただ, 健全な開発ならば APIに対するTestは 存在しているはず
  67. 67. そのTestからDocumentを 生成することで Docが遅れなくなる
  68. 68. で, 書いた
  69. 69. Test::JsonAPI::Autodoc https://metacpan.org/release/Test-JsonAPI-Autodoc https://github.com/moznion/Test-JsonAPI-Autodoc
  70. 70. 細かな差異はあれど, ほぼautodocのport
  71. 71. また, 似たコンセプトのものに Shodoというのがあり…
  72. 72. 後ほど説明が あると思います
  73. 73. 第Ⅱ部完
  74. 74. まとめ
  75. 75. TestとDocumentは 近い存在 協調できると思う
  76. 76. 協調すると, ドキュメントの破滅 などから救われる
  77. 77. TestとDocumentを 同居させる方法と TestからDocumentを 生成する方法は 割と良いのではないか
  78. 78. 双方の使い分けは ドメインに応じて
  79. 79. という感じ
  80. 80. 2013 DevOps ⇩ 2014 DocTest
  81. 81. Doc🍣Test
  82. 82. Any Q?

×