{"action":"created","issue":{"url":"https://api.github.com/repos/junit-team/junit/issues/1161","labels_url":"https://api.github.com/repos/junit-team/junit/issues/1161/labels{/name}","comments_url":"https://api.github.com/repos/junit-team/junit/issues/1161/comments","events_url":"https://api.github.com/repos/junit-team/junit/issues/1161/events","html_url":"https://github.com/junit-team/junit/issues/1161","id":85978724,"number":1161,"title":"JUnit needs a better story for extensibility","user":{"login":"rschmitt","id":3725049,"avatar_url":"https://avatars.githubusercontent.com/u/3725049?v=3","gravatar_id":"","url":"https://api.github.com/users/rschmitt","html_url":"https://github.com/rschmitt","followers_url":"https://api.github.com/users/rschmitt/followers","following_url":"https://api.github.com/users/rschmitt/following{/other_user}","gists_url":"https://api.github.com/users/rschmitt/gists{/gist_id}","starred_url":"https://api.github.com/users/rschmitt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rschmitt/subscriptions","organizations_url":"https://api.github.com/users/rschmitt/orgs","repos_url":"https://api.github.com/users/rschmitt/repos","events_url":"https://api.github.com/users/rschmitt/events{/privacy}","received_events_url":"https://api.github.com/users/rschmitt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-06-08T01:26:18Z","updated_at":"2015-07-08T19:11:16Z","closed_at":null,"body":"This issue is a continuation of the discussion in #1158. This is the essential issue, and it prevents me from using JUnit for anything other than toys:\r\n\r\n>It's starting to sound like the abstractions that JUnit provides are inadequate.\r\n>\r\n>On the one hand, we've got Runner, which is potentially very powerful, but that power can only be accessed through subclassing. I can't compose two different Runners to combine their effects.\r\n>\r\n>On the other hand, we have TestRule, which is interface-based and composes well, but which isn't powerful enough to safely extend or modify the way test methods are executed, therefore making them largely useless for anything other than simple callbacks (e.g. TemporaryFolder, ErrorCollector, Stopwatch) and filters (Verifier). The main exception is Timeout.\r\n\r\nThere are tons of interesting and useful custom test runners for JUnit, all of which are utterly non-interoperable with each other. They just don't compose, and there are really fundamental reasons why they can't compose under the current architecture. JUnit 5 would be a fantastic opportunity to tackle this problem. Is this something that people have been thinking about for a while? Is there a wiki or something that discusses potential design directions? The only things I'm aware of targeting JUnit 5 are (1) removal of Hamcrest matchers (yay), (2) removal of a really old runner (yay), (3) targeting of JDK6 (what's the point? Do you need `ArrayDeque` or something?)."},"comment":{"url":"https://api.github.com/repos/junit-team/junit/issues/comments/119699458","html_url":"https://github.com/junit-team/junit/issues/1161#issuecomment-119699458","issue_url":"https://api.github.com/repos/junit-team/junit/issues/1161","id":119699458,"user":{"login":"Fuud","id":283980,"avatar_url":"https://avatars.githubusercontent.com/u/283980?v=3","gravatar_id":"","url":"https://api.github.com/users/Fuud","html_url":"https://github.com/Fuud","followers_url":"https://api.github.com/users/Fuud/followers","following_url":"https://api.github.com/users/Fuud/following{/other_user}","gists_url":"https://api.github.com/users/Fuud/gists{/gist_id}","starred_url":"https://api.github.com/users/Fuud/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Fuud/subscriptions","organizations_url":"https://api.github.com/users/Fuud/orgs","repos_url":"https://api.github.com/users/Fuud/repos","events_url":"https://api.github.com/users/Fuud/events{/privacy}","received_events_url":"https://api.github.com/users/Fuud/received_events","type":"User","site_admin":false},"created_at":"2015-07-08T19:11:16Z","updated_at":"2015-07-08T19:11:16Z","body":"Ok. Lets try to write down something specific.\r\nI prefer to separate test execution in two stages: initial discovery and execution (execution can also discover something at run time).\r\n\r\nInitial discovery subsystem builds some sort of ExecutionPlan (from IDE side it is equal to Description). \r\n\r\n```\r\npublic interface ExecutionPlan {\r\n  TestResult run(RunListener listener);\r\n\r\n  TestResult run();\r\n  \r\n  List<ExecutionPlan> getKnownChildren();\r\n  \r\n  String getId();\r\n  \r\n  String getDisplayName();\r\n}\r\n```\r\n\r\nAll object creations, setups and cleanups, iteration over children etc are hidden into run method.\r\nIDE can use getKnownChildren to render test execution before test run.\r\n`run` returns TestResult thus it can be used programmatically like this:\r\n```\r\n  TestResult testResult = ClassicJUnit.parseClass(MyTest.class).run();\r\n  if (testResult.hasFailures()) ...\r\n```\r\n\r\n`ExecutionPlan` can have some well-known (by IDE developers and extension developers) implementations to support filtering, sorting, multithreading.\r\n"}}