Channels
#spek
- h
hhariri
10/07/2015, 8:44 AMSo we’d end up having to re-implement a bunch of things. - s
salomonbrys
10/07/2015, 8:46 AMI agree with you, so what choicesother than using the constructor are left ? - s
salomonbrys
10/07/2015, 8:47 AMIf you drop JUnit, you also drop Android 😞 - h
hhariri
10/07/2015, 8:47 AMWhat @mhshams was suggesting is another solution. - s
salomonbrys
10/07/2015, 8:49 AMSorry, I can't find what you are refering to, do you have a link ? - m
mhshams
10/07/2015, 9:18 AMI see my name here. Hi all :) - s
salomonbrys
10/07/2015, 9:19 AMHi 😉 - s
salomonbrys
10/07/2015, 9:20 AMHadi is refering to a proposal of yours but I can't find it 😞 - m
mhshams
10/07/2015, 9:21 AMyeah, let me find it in github - h
hhariri
10/07/2015, 9:21 AM@mhshams: cool, thanks. I couldn’t find it 😕 - m
mhshams
10/07/2015, 9:23 AMthe discussion is here: - m
mhshams
10/07/2015, 9:23 AM - s
salomonbrys
10/07/2015, 9:28 AMI'll look at that, thanks 😉 - u
user
10/07/2015, 10:40 AM@michel-slm commented on @yigit’s file https://kotlinlang.slack.com/files/U0B98KWF4/F0C0W1CM9/-.pl: hmm Slack needs to be taught what Kotlin is.. Perl indeed - d
desseim
10/07/2015, 11:01 AMgoing out on a limb, aren’t type-safe builders an option ? - h
hhariri
10/07/2015, 11:07 AM@michel-slm: I’ve pinged Slack on Twitter and they said they’ll get to it. I guess the more people voice their need for it, maybe the more attention they’ll pay. For now I just use Java…. - s
salomonbrys
10/07/2015, 12:31 PM@michel-slm: I guess they might make an effort when the language will reach 1.0. For now, they would need to change the parser at every millestone release... - o
orangy
10/07/2015, 2:28 PM@mhshams: I believe you still need an annotation for scenario, because there could be some other methods that are not test scenarios. E.g. shared code to setup some common part of “given" - o
orangy
10/07/2015, 2:29 PMAlso, there are too many names you have to create and for most cases those would be duplicate. I.e. class name, method name, given/on/it - m
mhshams
10/07/2015, 3:18 PM@orangy: yeah, you are right. This can be done either by annotation or by other approaches. for example all public methods with a specific declaration. (Spock framework uses a similar approach and it doesn't need annotation). - m
mhshams
10/07/2015, 3:18 PM@orangy: what do you mean by too many names? - o
orangy
10/07/2015, 3:47 PM@mhshams: I mean you need a name for a class, for method and then text for given/on/it, when basically all you need is just given/on/it text. - m
mhshams
10/07/2015, 4:03 PM@orangy: the class name should be there anyway, regardless of solution. (even in current solution, it is there). The method name for me is the title of scenario that is being tests. which is different from given/on/then - o
orangy
10/07/2015, 4:03 PMYou can get rid of class name by using top-level functions - m
mhshams
10/07/2015, 4:04 PMThat I agree, but then probably we won't be able to use JUnit to run them - o
orangy
10/07/2015, 4:05 PMwith something like
we can@file:RunWith(SpekRunner) - o
orangy
10/07/2015, 4:05 PMSpekRunner should be very special of course - o
orangy
10/07/2015, 4:12 PMideally we should be using scripting functionality, but it doesn’t really work yet - o
orangy
10/07/2015, 4:13 PMso you have a file named Foo.spek and it is handled as a kotlin script with default imports and all you have at top level is just given/on/it - m
mhshams
10/07/2015, 4:14 PMAnd scenario title ;)