LinuxMain template

[ilyapuchka]

Resolves #118

[krzysztofzablocki]

Let's ping @vknabel and @swizzler, since they know this usecase better, looks good to me.

[vknabel]

@ilyapuchka @krzysztofzablocki Sorry for the late response. In my case the stencil template got parsed wrong and therefore an error has been thrown. Maybe the Stencil versions declared by SwiftPM and CocoaPods got out of sync?

$ sourcery --version
0.5.3
$ sourcery Tests Templates/LinuxMain.swift.stencil Tests/LinuxMain.swift
Scanning sources...
Found 3 types.
Loading templates...
Loaded 1 templates.
Generating code...
2017-01-16 12:11:38.066 sourcery[37327:9309308] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<sourcery.Method
0x7fa0034144f0> valueForUndefinedKey:]: this class is not key value coding-compliant for the key shortName|hasPrefix:"stest".'

But everything else looks promising.

[ilyapuchka]

@vknabel I think that may be an issue, it should point to stencilproject/Stencil@99efba5

[krzysztofzablocki]

that's my bad, I'll update it in my next pr

[vknabel]

@ilyapuchka I have released a new tag. (Sourcery still needs to use my fork for Stencil)
Parsing the template now works as expected, but I'll need to test it on linux first,

[vknabel]

@ilyapuchka Works great! Shall be add some warnings when the methods/classes are not public? This would be an compile error on Linux.

[ilyapuchka]

@vknabel we ignore everything private at this moment. With #45 it will change of course. If there are private methods accessible then it's most likely a bug.

[vknabel]

@ilyapuchka by default they are internal, but the LinuxMain.swift is not inside the test target.

[krzysztofzablocki]

We should add access level filter if we don't have it, it will come handy

[ilyapuchka]

@vknabel That explains why I was using @testable to import test module =) So I guess there are different options. And yes, filters will be handy.

[ilyapuchka]

@vknabel actually I'm not sure about warnings, feels like it's better just to make generated code not to compile if user forgot to make test method public. If he does not want to include it in test he can always adjust template to use annotations for methods or to prefix those methods names with _ or what ever. But that's more like a general best practice for templates that we should recommend or not. @krzysztofzablocki what do you think?

[krzysztofzablocki]

why don't we just filter to only support public in the template? otherwise I'd agree with @ilyapuchka, if user misuses the template its better to make it not compile so they fix their setup

[ilyapuchka]

@krzysztofzablocki we can, but I guess the whole purpose of such template is to never have any tests missing because you forgot to add it in XCTMain. So now you don't have to add methods manually but you still can forget to make them public. If we filter methods in template nothing will remind user about missing test. So one way is not to filter and make it fail to compile, another one is to filter but when filtering leave a comment in code.

[krzysztofzablocki]

I'd go with fail to compile, Sourcery driving goal is to limit human errors

[vknabel]

@krzysztofzablocki @ilyapuchka Sorry for the confusion. It's good that the build breaks when one test is not public. At least it breaks when testing on Linux. Initially I thought about additionally marking non-public tests with a comment ("testSomething", testSomething) // You need to mark this declaration as public, but that would mean that warnings would eventually be committed, which is bad.

Instead I would just mention in the <details>, that the tests need to be public and hope that everyone reads it.

But this template works great. 👍