プログラマーなら単体テスト(UT)も実装しよう

1 ：2013/04/07 〜 最終レス ：2013/06/13

おまえらちゃんとテスト作ってる？
テストメソッドの名前
どういう単位でテスト実装してるか
テストのためにアクセス指定子変える派とリフレクション使う派とどっちが多いのとか

2 ：

関連しそうなスレ
マ
テストを軽視する者ども
http://kohada.2ch.net/test/read.cgi/prog/1214650160/
テストデータに「test」とか「てst」とかもうやめろ
http://kohada.2ch.net/test/read.cgi/prog/1127447938/
ム
テストしにくいコードをテストする方法教えて下さい
http://toro.2ch.net/test/read.cgi/tech/1334408391/
テストを書いてからリファクタリングなんてのは幻想
http://toro.2ch.net/test/read.cgi/tech/1349191466/
【TDD】テスト駆動開発【TestFirst】
http://toro.2ch.net/test/read.cgi/tech/1284899172/

3 ：

最近糞コードのテスト書いてるから辛い
TDDやれとまでは言わんが、せめてテストできるレベルの実装位できるようになって欲しい
つかnUnitの使い方すら理解できないクズはプログラマー辞めちまえって思う

4 ：

>>4
クソスレ立てんな

5 ：

>>5
お前の指図は受けない

6 ：

>>6
誰に向かって口聞いてんだ

7 ：

　 　 _, ,_ 　ﾊﾟｰﾝ
　（　‘д‘）
　　⊂彡☆))Д´） >>7

8 ：

うちの職場にもJUnitとかの使い方が分からないレベルの奴ごろごろいるから悲しいわ

9 ：

>>7
自分を叩いてどうする

10 ：

>>10
空気読めないのかお前は

11 ：

>>11
うるせーハゲ

12 ：

>>12
おままえがなー

13 ：

僕の魔チンポが暴発しそうです

14 ：

>>14
お前だけが希望だ

15 ：

なんだよ、このグダグダな流れは....
>>15
きちんと責任とれよ！！

16 ：

どうせおまえらUTとか作ってないだろ

17 ：

うちの職場のオッサン、JUnitの使い方分からないし単体テストとか実装してすらいないのに
テスト終わったとか嘘言って糞コードコミットしてくるからマジしねばいいのに

18 ：

教えてやれ

19 ：

リフレクション使ってテスト書くくらいならパッケージプライベートとかアクセスできるようにしておくかなー

20 ：

Ｆ言語でもできんのかよふざけんな

21 ：

メイン言語はJavaだけど、JUnitでテスト書くようになってからprivateメソッドはあんまり書かなくなったな
パッケージプライベートやprotectedを良く使う
メソッド単位でテスト書いたほうが楽だし工数も減るし、リファクタリングとかも捗る気がする
こういうやり方って実際どうなの？publicメソッドのテストケースしか書かないのが普通？
ちゃんとしたテストコードってのを見た事が無くて、どうやるのがいいかいまだによくわからない

22 ：

Javaだとどうなんだろうね。
Objective-CもGoも、やろうと思えばプライベートメソッド呼べるしな。

23 ：

>>21
ここを参照。
「プライベートメソッドのユニットテストは書かないもの？」
http://qa.atmarkit.co.jp/q/2784
なお、最初の回答のt_wadaが誰なのか知らなければ、和田卓人でググるとテストに関連する記事とか読める。

24 ：

プライベートかどうかは関係ない。
テストの目的を考えれば、間違いやすいならば
テストを書くということは明らかにわかるはず。

25 ：

関係ないことないでしょ。
privateに対するテストがあると、リファクタリング邪魔になったり、実装詳細を変更したらテストもメンテする必要がでてきたりする。
基本はpublicに対するテストだけでいいと思う。

26 ：

それはpublicに対するテストの話だからそうなる。
テストはユニットテストだけではない。
privateのテストがあるとリファクタリングのじゃまになったり
実装詳細を変更した時にメンテをする必要があるが、
それはprivateのテストをしない理由ではない。
privateのテストはリファクタリングのじゃまになったり
実装詳細を変更した時にメンテをする必要があるが、
そのデメリットよりもメリットが上回ればやる勝ちはある。
なお、publicでもリファクタリングじゃまになったり
メンテをする必要があったりする。
なぜならば、インターフェースを変える修正もあるからだ。

27 ：

クラスの粒度がやっぱり大きすぎるのかなぁと感じる
プライベートメソッドを別のクラスのパブリックメソッドにしてしまえばこういう悩みはなくなりそう
でもクラス分けすぎると古い脳の人が混乱するからって怒り始めるし、むずかしいなぁ

28 ：

ユニットテストは仕様に対するテストのことであって、
リファクタリング（外から見た形は変えずに内部の改善をする）を
行うためためだけに存在するわけじゃない。

29 ：

つーか、ハードウェアの自己診断テストみたいに考えればいいんだよ。
あれはハードウェア内部のテスト。つまりprivateテストみたいなもん。
ハードウェアの自己診断テストでどんなテストを行なっているかは知らんが、
外からは（LEDや音などで）テスト結果がわかる。
それと同じでpublicのself_test()メソッドを呼び出して、その中にテストコードを書く。
外部から見れば、self_test()が仕様通り（自己診断テストにtrueを返すか？）を確認するだけだし、
ハードウェア内部の自己診断テストは、自己が仕様通りかテストをすればいい。

30 ：

publicのメソッドを実行すればprivateメソッドは内部で呼び出されるんだから
publicメソッドのテストだけをやればいいという考えなら、
それに対して、システムテスト、統合テストを行えば、
publicメソッドは呼び出されるんだから、ユニットテストはいらないんじゃね？
という考えも成り立つよなと言いたくなる。

テストはなるべく小さい粒度でやるべき。それは問題は小さい方で解決したほうが
コストがかからないから。このあたり前の理由がprivateメソッドのテストにも当てはまる。
粒度が大きすぎるなら、当然小さい粒度でやるべき。粒度が問題なのであって
それがクラス内部からしか使わないのであれば、それはテストすべきprivateメソッドということになる。

31 ：

privateメソッドのテストはユニットテストじゃねーよというのであれば、
じゃあ「ユニットテスト」とは違う名前を付けないといけないねって話になるだけ。
ユニットテストをしないが、それはテストをしないという意味ではない
ユニットテストと違う名前、つけていいと思う。例えば自己診断テスト。

32 ：

Javaマだけどパッケージプライベートにしてテスト書いてる
あと、そういう可視性をあげたフィールドやメソッドには、Guavaの@VisibleForTestingアノテーションとかつけたりしてる

33 ：

あとTDDしてないけど、実装とリファクタリング平行しながらテストも書いてるから
パブリックメソッドだけに全ケース網羅できるようなテスト書くのはちょっとしんどいってのもある
クラスが大きすぎるんだろうけど、細かく分け辛い処理(名前が付け辛い処理)って、
業務系クラスだと結構多くて外に持ってくのしんどいのよね

34 ：

>>32
それもありだとは思う。思うけど言語の機能に依存する。
privateメソッドを呼び出す機能が存在しないと使えない。
あと、privateのテストを行うモジュールとpublicのテストを行うモジュールは分けたほうがいいかもしれない。
publicのテストを行うモジュールはユニットテストの目的通り「外部から見た仕様をテストする」もの。
それに対してprivateのテストを行うモジュールは、内部で使われている一機能をテストするもの。目的が違う。
あとprivateメソッドのテストはメソッド全てに対して行う必要はない。publicでも結局は一緒なのだけど、
テストを行うメリットとデメリットを考え、テストを行うメリットがある場合だけテストすればいい。
全部やってて時間が足りるのならやってもいいけど。

35 ：

網羅するためにPublicメソッドのテストケースを複雑かつ多種用意するくらいなら、
もっと小さい単位のメソッドで網羅して、パブリックメソッドはパスだけテストするほうがコストはかからないね。
リファクタリングには使えないけど、ぶっちゃけちゃんと作れてたら早々大きなリファクタリングは発生しない。

36 ：

別にリファクタリングに使えないってこともないんだ。
privateメソッドの仕様が変わらず、
内部だけを修正することもある。
長いprivateメソッドを修正し、そのコードの一部を関数化し、
それを汎用モジュールのpublicメソッドにする。
なんて話だってあるだろう。

37 ：

最初からちゃんと作るというのは、実際には不可能な話で、
だって成長するわけで、誰だって昔の自分はだめなもんだろう？
重要なのは最初から正解を出すことではなく、
どうやって間違ったものを正しくするまでの
道順を考えることだろう。

38 ：

>>34
> privateメソッドを呼び出す機能が存在しないと使えない。
ん？
そもそもprivateメソッドをテストできるかどうかが、言語依存（あるいは処理系依存）じゃないの？
概念としての「プライベートなクラス」に括り出すのなら、C++でも似たようなことはできるよね。
ライブラリとしてまとめて、exportしなければいい。

39 ：

>>30
> それに対して、システムテスト、統合テストを行えば、
> publicメソッドは呼び出されるんだから、ユニットテストはいらないんじゃね？
> という考えも成り立つよなと言いたくなる。
いや、ならないよ。
まず、ユニットテストと結合テストでは行う時期が違う。
バグは早く見つけられれば見つけるほど、修正コストが小さくて済む。
次に、結合テストはたいていの場合ブラックボックステストで行い、要件ベースでテストケースを作成する。
ユニットテストはホワイトボックステストで、コードベース、あるいは、プログラマの意図でテストケースを作成する。

40 ：

>>39
だからなに？理由になってないんだが。
時期が違ったからって、統合テストで問題なければ
publicメソッドのテストは不要だろ？
要件ベースでテストした時、
コードにバグがあればテストに通らないだろ？
統合テストやればユニットテスト不要じゃん。

41 ：

>>40
何が言いたいかって、単体テストの時にprivateメソッドをやるかどうかという問題と、単体テストを省略して結合テストをやればいいだろという問題は、全く別問題であるという至極普通なことなんだけど。
全く別問題であるがゆえに、仮に単体テスト時にprivateメソッドのテストしなくてもいいと主張したとしても、それが結合テストをするから単体テストは不要ということにはならない。
というか、privateメソッドのテストをすべきどうかは、単体テストの枠組み内で考慮すべき問題なのに、結合テストを持ち出すお前の方が何を言いたいのかさっぱりわからんわ。

42 ：

>>41
「結合テストをするからといって、単体テストは不要といういう事にはならない。」って俺が言ってることなんだけど？
それと同じで、
「publicテストをするからといって、privateテストは不要という事にはならない。」も成り立つって言ってんの。

43 ：

>>42
話が微妙に変わってる。もう一回>>30を読み直してみろ。
単体テストでpublicのテストをすればprivateが呼び出されるからprivateのテストは不要と言うのであれば、結合テストをすればpublicメソッドが呼び出されるから単体テストは不要とも言える、というのがお前の主張。
で、そうは言えないというのが俺の主張。理由は前述の通り。

44 ：

それに、そもそも単体テストではpublicメソッドのみをテストするのが良いという理由は、privateメソッドはテスト中に呼び出されるから不要だからではない。

45 ：

>>43
お前の言う理由が理由になってないという話。
例えば行うテストを行う時期が違うことは
privateメソッドをテストしない理由にはならない。

46 ：

単体テストでpublicメソッドのみをテストするのはいいが
それはprivateメソッドをテストしない理由にはならない。
privateメソッドをテストするとデメリットが有るが
そのデメリットよりも、テストをするメリットが高ければ
テストをした方がいい。
要するにテストするかしないかは、そのコードはテストをしなければ
バグが出やすいかどうかってだけ。

47 ：

ここも妄想癖が強い人の一人相撲

48 ：

相撲は一人じゃ出来ません。
相手がいるんだよｗ

49 ：

>>45
テストを行う時期が違うからprivateメソッドのテストをしないとは一言も言ってないが。
privateメソッドのテストをしないというなら、publicメソッドも結合テストでテストされるからしなくていいとも言える、という論理は成り立たないと言ってるんだが。
さらに言えば、俺がすべきでは無いと思ってるのは、privateメソッドをprivateメソッドのままでテストすべきでは無いということ。
更に言うなら、君のprivateメソッドをテストする価値があるならやるべきという立場も否定はしない。俺はやらないが。
俺が否定してるのは、君が俺の立場が間違っているという論拠がおかしいといただそれだけのことだよ。

50 ：

> という論理は成り立たないと言ってるんだが。
お前皮肉もわからんの？
publicメソッド経由でテストしてるから不要と抜かしている馬鹿に対して
そんなのは理由にならないと皮肉を言ってるんだが？
> privateメソッドをprivateメソッドのままでテストすべきでは無いということ。
じゃあどうするか？
１．privateメソッドを呼び出すだけのpublicメソッドを作る
２．privateメソッド＋別の処理を行うpublicメソッドを作る（または利用する）
1はジョークとしか思えない、2はなぜ複雑にしてテストをしないといけないのか？
テストはシンプルな状態でやるべき。
そしてなるべく早く、privateメソッドが出来た時点でやるべきだ。

51 ：

privateメソッドをテストしないの理由を聞いていてわかるのは
privateメソッドは外部から呼び出せないから
テスト出ないだけ。
その言い訳として、あーだーこーだいってる。

52 ：

話が通じないわー。

53 ：

それは俺のセリフ。
俺がprivateメソッドテストをしない理由はないといって
それに反論してないだろ？
それで話は終わりじゃないか。

54 ：

>>53
>>25でしない方がいい理由を書いてるんだが。
君はそれを大した根拠もなく、それは理由にならないとしか言えてないよ。

55 ：

>>54
いや、だからテストをメンテする必要があるから何なの？って話。
メンテスレばいいだけでしょ？
それにそもそもの話がある。
Q. 本当にprivateメソッドのテストをメンテする必要があるか？
A. privateメソッドの仕様が変わらないなら、privateメソッドのテストをメンテする必要はない。
Q. publicメソッドのテストはメンテしなくてもいいのか？
A. publicメソッドの仕様が変わるなら、メンテする必要はある。
publicでもprivateでも仕様が変わればテストをメンテする必要があるし、
仕様が変わらないのならメンテの必要はないんだよ。

56 ：

ねぇ、private関数を作るときに、private関数単体でテストしないの？
別にユニットテストとか書くとかいう話じゃないよ。
ステップ実行とかでいいからさ、
関数単位でテストしないの？

57 ：

>>55
工数が増えるからといってそれが何なの、と言ってるようにしか聞こえません。
工数が増えるのは問題ですね。

58 ：

>>56
だから、しないって。

59 ：

>>57
テストのための工数を嫌がってるようにしか見えないが？

60 ：

>>55のQ ＆ Aに対する反論がないなｗ

61 ：

結論は、t_wadaは馬鹿であるってことでいいのかな。

62 ：

結論は、t_wadaは馬鹿であるってことでいいのかな。

63 ：

どう見ても馬鹿は>>30

64 ：

と罵ることしか出来ないのであった。ああ無能。

65 ：

リファクタリング中に、テストが失敗しないことで正しさを担保できるのに、privateメソッドのテストのせいでテストが失敗し、カオスになる。
publicA()の為にprivateA()を作り、privateA()のテストを書いた。publicB()でもprivateA()をつかいたいけど、ちょっと引数を変更しなきゃ。おっと、テストが失敗しまくるぜ。
でも大丈夫。。。俺らには無限の時間があるし。テスト工数をけちっちゃけちっちゃ駄目だよね。

66 ：

そもそも論で言うなら、privateメソッドを外部からの呼べる言語の方が少ない訳だから、
privateメソッドをテストすべしというのは最初からおかしいんだが。

67 ：

それは理由にならないよ

68 ：

なんで理由にならないんだ？
privateメソッドのみならず、クロージャとか無名メソッドとか、普通は外部から呼べないよね。
呼べないんだからそれはそのまま単体ではテスト出来ませんねってなるのが普通。

69 ：

privateメソッドは実装詳細なんだから、そのクラスを実装中に引数が変わったり実現内容が変わったりは
よくあること。
publicだって変わることがあるというが、それはprivateと頻度が違う。
そんなにころころpublicのI/Fが変わるとしたら、それは実装のやり方が間違ってるよ。

70 ：

>>65
意味不明。
> リファクタリング中に、テストが失敗しないことで正しさを担保できるのに、privateメソッドのテストのせいでテストが失敗し、カオスになる。
それはprivateかどうかではなく、
テストしているメソッドの仕様を変えたからだろ
publicメソッドでも同じ事あるわ。
リファクタリングのうち単純な「メソッド名の変更」と呼ばれるものであっても
テストを修正しないとテストは失敗する。
リファクタリングとはね、システムの挙動を変えない変更であって
クラス単体の内部の修正ではないんだよ。

71 ：

>>69
> そんなにころころpublicのI/Fが変わるとしたら、それは実装のやり方が間違ってるよ。
確かにpublicがワールドワイドでpublicならそうだろうね。
世界中で使われているライブラリのpublicメソッドがころころ変わるわけがない。
だがプロジェクトローカルなpublicメソッドだったらどう？
単にひとつの画面をMVCで作ろうととなって、Modelのメソッドは仕方なく
publicにしないといけないが、そのメソッドを読んでいるのは特定の画面のみ。
プロジェクトの開発者が少なければ、ころころ変えても問題無いだろ。

72 ：

>>70
それこそ意味不明だわ。
既存のprivateメソッドで、より適切な名称を思いついて変えようとする。
その程度のことでさえ、そのprivateメソッドのテストがあるとテストが失敗してしまう。
リファクタリングのことわかってないんじゃないの？

73 ：

>>71
だから変更される頻度が違うって言ってるじゃん。
実装詳細は、公開インターフェイスに比べて変更されやすい。
その都度テストメソッドの修正が必要だとしたら、それこそ改善の足かせになってるよね。

74 ：

>>72
既存のpublicメソッドで、より適切な名称を思いついて変えようとする。
その程度のことでさえ、そのpublicメソッドのテストがあるとテストが失敗してしまう。

>>73
publicが変更されにくいってのはわかるが
privateが変更されやすいとは限らないだろ。
特に関数にするようなものは変更されにくい。
ロジックは書き換えるが、
メソッドは変更されにくいんだよ。

75 ：

×メソッドは変更されにくいんだよ。
○メソッドのインターフェースは変更されにくいんだよ。
たとえprivateであってもな。

76 ：

>>74
クラス内部の構造を改善するリファクタリングしないの？
publicメソッドもprivateメソッド変更されにくいって、それでどうやってリファクタリングするわけ？
publicメソッドの仕様を変えれば、それを使っている所もテストコードも変更するのは当然。
でも、それはprivateメソッドのテストを書くべきかどうかとは関係ないよね。

77 ：

なんか言ってることがループしてるな。
privateメソッドは(一般的に)テストをかけない。
→ テストがないから変更しやすい。
→ 変更しやすくするにはテストを書かない。
→ テストがないもの(書けないもの)は変更しやすい。
→ 変更しやすくするにはテストを書かない。
→ テストがないもの(書けないもの)は変更しやすい。
→ 変更しやすくするにはテストを書かない。
→ループ

78 ：

>>75
君がそうだからってみんなそうであると決めないでよ。
実装詳細はその時の状況によって、容易に変更されうる。そして、通常は外部との結合は
無いのだから気軽に行える。その変更の正しさを担保するのがpublicメソッドのテスト群。
設計の基本は、高い凝集度と低い結合度だ。
本来必要ないのに、privateメソッドの結合度を高めてどうするんだって話だよ。

79 ：

>>76
> クラス内部の構造を改善するリファクタリングしないの？
> publicメソッドもprivateメソッド変更されにくいって、それでどうやってリファクタリングするわけ？
リファクタリング＝クラス内部の構造だけの修正じゃないぞ？
クラス構造そのものやメソッドのインターフェースを変えるリファクタリングもある。
インターフェースを変えるリファクタリング方法が存在するのだから
それをprivateメソッドにも同じように適用すればいいだけ。
リファクタリングをちゃんと知ってるのなら、privateメソッドも
リファクタリングできるってわかるはずなんだがな？

> publicメソッドの仕様を変えれば、それを使っている所もテストコードも変更するのは当然。
> でも、それはprivateメソッドのテストを書くべきかどうかとは関係ないよね。
だからそう言ってるだろ。
メソッドのテストを書くべきかどうかは、publicとprivateは関係ない。
メソッドの使用を変えれば、それを使ってるテストコードも変更するのは当然。

80 ：

>>78
> 実装詳細はその時の状況によって、容易に変更されうる。
↓
君がそうだからってみんなそうであると決めないでよ。
容易に変更されないメソッドもある

81 ：

>>77
ループしてると思ってるのは気のせいだよ。

82 ：

>>78
> 本来必要ないのに、privateメソッドの結合度を高めてどうするんだって話だよ。
なら結合度を高めなければいいだけ。
クラスにself_testってメソッドを作って、
テストの実行は、クラス自身にやらせれば、
外部からのインターフェースは変えずに
privateメソッドのテストを行える。

83 ：

>>79
話が通じないわー。

84 ：

>>83
お前がなｗ

85 ：

結局のところメソッドのインターフェースの変更が
変わらなければテストは変えなくていいが、
インターフェースが変わればテストの変更も必要。
これはpublicやprivateは関係ないのに
結びつけようとしているのが間違いなんだよな。

86 ：

>>82
そうしたら、今度はそのself_testの存在が、実装詳細の変更を阻害する要因になるってのが
わからないのかなー。

87 ：

>>85
なんでprivateメソッドのテストが存在することが前提になってるんだよ。
俺は、そのテストがなければ自由に実装詳細を変えられるって話をしてるんだが。

88 ：

>>86
阻害しないよ？
なぜなら、privateメソッドのインターフェースを
変更しなければ、テストの修正は不要だから。

89 ：

テストがなければ、コードを書き換えても
テストに失敗しない！
全てのテストをなくそう！

90 ：

>>88
privateメソッドを直接テストするコードの存在が、実装詳細の変更を阻害する要因になるってのが理解できないの？

91 ：

なんですべてのprivateメソッドにテストコードを書くって
思い込んでるのさ？（笑）
一部の複雑なコードでいかにもテストが必要だってコードに対して
じゃあ、仕様変えないようにきっちり作ってテストしようか。
でも外部からは呼び出さないからprivateでいいよね。
って話だろうが。

92 ：

>>90
> privateメソッドを直接テストするコードの存在が、実装詳細の変更を阻害する要因になるってのが理解できないの？
じゃあ、そのメソッドをpublicに変更しろよ！
そうすれば、テストコードあっても、実装詳細の変更を阻害する要因にならないって
お前の馬鹿な脳でも理解できるだろ？
それpublicメソッドが今回はたまたま外部から呼び出す必要がなかったから
privateだったってだけだ。

93 ：

全然かみあってないなｗ

94 ：

>>91
だから、そのprivateメソッドのテストの存在が、実装詳細の変更を阻害する要因になるってのが理解できないの？
その意味で、publicに対するテストとprivate対するテストでは事情が違うと言ってるのに。

95 ：

> だから、そのprivateメソッドのテストの存在が、実装詳細の変更を阻害する要因になるってのが理解できないの？
お前が言っていた理由は全て否定されてる。
何度言っても、理由が書いてないものは
誰にも受け入れられない。

96 ：

>>92
いきなり何を言い出すんだよ。
俺はprivateメソッドのテストの是非を語ってるんだが。

97 ：

>>95
理由は書いただろ。

98 ：

>>96
俺はテストが必要かどうかにpublicとprivateは関係ないと
言ってるから、何の問題もないが？

99 ：

>>97
それ（>>92等)に対する反論がないじゃないか。
publicにしたらテストするのに、
それをprivateに戻したらテストしないって
おかしい話だろ。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

JavaScriptプログラマーだけど何か質問ある？ (184)
プログラマー川柳 (202)
残業してるおまいらが食いたいものを書くスレ (106)
プログラム言語統一すればよくね？ (109)
高木浩光先生のスレッド Part32 (148)
ラッキョを机で転がすスレPart2 (119)
--log9.info------------------
昔のガンガンを語るスレ　2号 (146)
【鳥羽僧正】　鳥獣戯画　二巻目　【日本最古】 (106)
【ワースト】小室孝太郎３【ミステリオス】 (104)
【ナーガス】増田晴彦スレ【風の騎士団】 (118)
修羅の門　第弐門　80勝目 (947)
【ｼﾞｬﾝﾌﾟSQ】青の祓魔師PART30【加藤和恵】 (374)
コミックランキング売り上げ議論スレPart240 (867)
名探偵コナン　ネタバレスレ71 (544)
DEAR BOYS act3 Vol.26 【八神ひろき】 (358)
【押見修造】惡の華（悪の華）Part13【別冊少年マガジン】 (675)
【諫山創】進撃の巨人Part178【別冊マガジン】 (397)
別冊少年マガジン 総合スレッド21冊目 (714)
別冊少年チャンピオン7 (572)
【キン肉マンPART525】　素手での打ち合い編 (813)
月刊少年チャンピオン (226)
【新川直司】 四月は君の嘘 【月刊少年マガジン】 (916)
--log55.com------------------
【ゆく年くる年17-18】 日本共産党総合Part 141
【ブーム終了】希望の党26【排除発言】
【飽きられた】希望の党26【オワコン政党】
世論調査総合スレッド419【ﾜｯﾁｮｲ導入】
第48回衆議院議員総選挙・議席予想情勢スレ 反省会スレ その25
自由党応援スレッド12
【昭和】政界懐古スレ Part44【平成
【再復活の】野党政局総合スレッド　【本スレ】多分 Part.39