makeawishfoundation / swiftymocky Goto Github PK

At this point, we can use either wildcard .any, or explicit .value. It would be nice to have third option - matching, to be able to cover wider range of attributes.

Also, add some additional library methods, like:

func stubFatalError(methodName: Stirng) -> Never {
  let failureMessage = "MESSAGE" 
  print(failureMessage)
  fatalError(failureMessage)
}

For sake of handling matcher and stub issues.

Would be nice, if given will support following:

Given(mock, .method(willReturn: 0,1,2,3,4))

_ = mock.method() // 0
_ = mock.method() // 1
_ = mock.method() // 2
_ = mock.method() // 3
_ = mock.method() // 4

We need to add support for protocol members based on Self requirement.

There is a problem when a protocol has overloaded functions where the signatures differ only in their return type. For example:

//sourcery: AutoMockable
protocol FunctionsThatDifferOnlyInReturnType {
    func foo(bar: String) -> String
    func foo(bar: String) -> Int
}

In that case only for the first function a mock is created and the build fails since the generated class does not conform to the protocol.

Is there a solution for the problem, except of renaming one of the functions?

Handle fatal errors with style, or at least print issues to console.

Similar as in R.swift - we want to value stability. For protocols that cannot be mocked for some reason - we want to skip generation, and show warning with detailed description.

I know this isn't really an issue with SwiftyMocky since the fix needs to happen in Sourcery but I wanted to bring it up over here since this where I got the swifttemplate from. I also created an issue here krzysztofzablocki/Sourcery#565

Error I get is here:

Using configuration file at '.sourcery-streetyapi.yml'. WARNING: Ignoring the parameters passed in the command line.
Scanning sources...
Found 116 types.
Loading templates...
Loaded 4 templates.
Generating code...
error: Error Domain=NSOSStatusErrorDomain Code=-1 "kCFStreamErrorHTTPParseFailure / kCFSocketError / kCFStreamErrorDomainCustom / kCSIdentityUnknownAuthorityErr / qErr / telGenericError / dsNoExtsMacsBug / kMovieLoadStateError / cdevGenErr: Could not parse the request/response. /  / custom to the kind of stream in question  /  / queue element not found during deletion /  / not a SysErr, just a placeholder  /  / General error; gray cdev w/o alert" UserInfo={terminationReason=__ObjC.NSTask.TerminationReason, error=dyld: Symbol not found: __T0s11_StringCoreV22isRepresentableAsASCIISbyFSbs6UInt16VcfU_
  Referenced from: /Users/<username>/Library/Caches/Sourcery/AutoMockable.swifttemplate/../SourceryRuntime.framework/Versions/A/SourceryRuntime
  Expected in: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftCore.dylib
 in /Users/<username>/Library/Caches/Sourcery/AutoMockable.swifttemplate/../SourceryRuntime.framework/Versions/A/SourceryRuntime
}

We might need to specify some contribution guidelines and conventions.

Allow adding SwiftyMocky through Carthage

For basic types, we should register default comparators.

Types to handle:

• Bool
• String
• Float
• Double
• Character
• Int
• Int8
• Int16
• Int32
• Int64
• UInt
• UInt8
• UInt16
• UInt32
• UInt64

SwiftyMocky does not currently handle the case for a protocol that inherits a requirement of NSObjectProcol. The derived mock needs to be a subclass of NSObject for this to compile.

I found a bug when generic methods differ only in a generic return type:

    func foo<T>(bar: String) -> Array<T>
    func foo<T>(bar: String) -> Set<T>

At least for that simple example I fixed it in #112. I’m not sure, if it still works, when the functions have several/other generic parameters.

After upgrading to version 1.0.1, it works fine with XCode 9 but fails with XCode 8.3. Aren't we supporting backward compatibility?

I have this protocol:

public protocol Networking: AutoMockable {
    func upload<T>(resource: Resource<T>) -> Observable<Response<T>>
    func responseUpload<T>(resource: Resource<T>) -> Observable<(HTTPURLResponse, Data)>
    
    func load<T>(resource: Resource<T>) -> Observable<Response<T>>
    func responseLoad<T>(resource: Resource<T>) -> Observable<(HTTPURLResponse, Data)>
}

Which generated this code and fails to compile:

Getting "fatal error: [FATAL] stub return value not specified for " after adding new unit test cases.

It generates warning in generated code, when attribute is same as its label.

Methods with generic constraints should be handled.

Perform method, that will be called by mocked method, allowing to perform action for passed attributes.

Handling completion block methods.

Make Swift 4 default for SiftyMocky.

For now Mocky supports only XCTestCase, i'd be nice to separate framework completely from XCTest, and open support for other platforms.

Generated mocks should handle @escaping / @nonescaping

At this point, our travis runs tests with same config as whole example project, so Swift 4 etc.

We might need environment, to constantly verify, if our setup is also valid for swift versions 3.x

We need some good examples, that will help to present SwiftyMocky features.

Currently we can just describe how many invocations we are expecting.

func Verify<T: Mock>(_ object: T, _ count: UInt, _ method: T.Verify, file: StaticString = #file, line: UInt = #line)

We need to add ranges, for instance:

• at least once
• never
• moreThan
• lessThan

During development I have encountered a problem with mocking the objects with generic metatype like:

func example<T>(with typeParam: T.Type)

After mocking an object with function like the one above, the resulting generated Mock fails the build with error
Swift Compiler Error (in Mock.generated.swift): Use of undeclared type ‘T’

I would like to ask if the issue is known for you and if there is solution for the problem?

Update docs, specs and project for final project name.

Update project structure (needed for docs generation).

Release v 1.0.1. Fixes and updates to documentation. Updated changelog, updated links and images for https://cocoapods.org/pods/SwiftyMocky

For some cases, it might make sense (might it?) to stub "real" implementations. That would require to enable adding AutoMockable not only for protocols, but also for non-final classes.

What Mock version could add is:

• stubbing return values (otherwise super called?)
• perform on method called (similar for properties?)
• verify method calls and properties get/set calls

Thing to be discussed.

Prepare full documentation for:

1. wiki
2. cocoadocs (jazzy generated? - include additional doc files)
3. simplify readme

Still needs to be done:

• Examples
• verify links to docs in readme

XCode 9 gives compile time error when built with SwiftyMocky.

When methods implemented in protocol extension (with default values) - mock methods become duplicated. Should use plain protocol methods.

I just tried SwiftyMocky with the newest XCode 9.3 beta. But I couldn’t compile it, since there is an ambiguous use of 'Matcher.register()' and 'Parameter.compare(lhs:rhs:with:)' when the parameters are arrays. I guess, this is related with changes in Swift 4.1.

Verify getters and setters being called. For setters, we might want to utilise Parameter concept, to verify explicit setters called.

In general, it could look something like:

Verify(mock, getter: .propertyName)
Verify(mock, setter: .propertyName(with: .any))
Verify(mock, setter: .propertyName(with: .value(...)))

Same concept for generation as for other mock cases, So Mock.Setter and Mock.Getter associated types maybe?

Add support for give/verify/mock and generation for static methods.

Hi Team,

While integrating SwiftyMocky, we found one issue. Thought of sharing it here -
If one protocol, say B, is conforming to another protocol, say A and we use SwiftyMocky to generate mocks for both A & B. In that case, since methods of protocol A are not generated/added into BMock, code doesn't compiles and throws error as below:
"BMock doesn't confirm to the protocol A."

Please let us know if we have a workaround for this or it is being fixed soon.

Hi,

I have an issue when I try to generate a mock from a protocol that has a function like the following:

func decode<T: Decodable>(_ type: T.Type, from data: Data) -> T

Due to the .Type the generic is lost in the generation.

Do you know about this? And does a workaround exist?

Release version 1.0.2.

Including:

• #85
• #76
• #84
• #83
• #80
• #81
• #82

Add link to license, fix links on cocoa pods.org (for local assets like guides)

We have quite good documentation, but we need articles that will introduce new users to concept of using this library.
I'd be nice to prepare following articles:

• Unit testing on iOS, best practices, how to write code to be testable
• SwiftyMocky - how to use it, how to start, live coding video?
• Comparison SwiftyMocky vs Cuckoo

@amichnia what do you think?

Verify and update for all stuff regarding throwing errors. Could think about Given versions with willThrow instead of willReturn.

Support for subscripts in protocol definition.

As @CurlyHeir mentioned - Mock.generated.swift could be quite big, making future generations slower if being scanned as well.

We should probably exclude all *.generated.swift files from scanning by default.

As we want to cover multiple platforms, we need to rearrange a bit project structure, while allowing to share same tests and mocks for test cases.

TODO:

• regenerate docs
• add changelog
• check podspec - should be expandable on github?
• bump version
• pod trunk

Hi guys,

First of all thanks for all the hard work you've put into this project, it looks great. I wanted to try out SwiftMocky in one of our projects and hit an error right away at the mock generation phase.

I am using Xcode 9.2, Swift 4.0.3. I installed SwiftMocky (1.0.2) through Cocoapods (1.3.1) configured the mocky.yml file as instructed in the docs and run :

Pods/Sourcery/bin/Sourcery.app/Contents/MacOS/Sourcery --config mocky.yml

I get the following output

Using configuration file at 'mocky.yml'
Scanning sources...
Found 582 types.
Loading templates...
Loaded 1 templates.
Generating code...
error: /var/folders/s2/xq1bmrbn2y9grg4m2_lppplr0000gq/T/Sourcery.build/main.swift:2:8: error: module compiled with Swift 4.0 cannot be imported in Swift 4.0.3: /var/folders/s2/xq1bmrbn2y9grg4m2_lppplr0000gq/T/SourceryRuntime.framework/Modules/SourceryRuntime.swiftmodule/x86_64.swiftmodule
import SourceryRuntime

I suspect that the SourceryRuntime lib is precompiled using a different version of Swift. Do you have a workaround to this issue?

Mock generated should handle init requirements