Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions custom-words.txt
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,7 @@ SDLC
Serilog
signtool
signup
Sourcery
sqlcmd
struct
structs
Expand Down
48 changes: 48 additions & 0 deletions docs/architecture/mobile-clients/ios/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -444,3 +444,51 @@ This makes it convenient to switch between these files or open them side-by-side
mode, dark mode, and with a large dynamic type size. โš ๏ธ These tests are done using an **iPhone 15
Pro (17.0.1)** simulator, otherwise tests may fail because of subtle differences between iOS
versions.

### Mocks generation
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

๐ŸŽจ Heading structure: Consider using a more descriptive heading like "Mock generation" instead of "Mocks generation" (singular form is more standard in English).


We use [Sourcery](https://github.com/krzysztofzablocki/Sourcery) for automatic mock generation.

In order to automatically generate a mock from a protocol, just add a comment with
`// sourcery: AutoMockable` to such protocol, perform a build and the mock will be automatically
generated and added to the `AutoMockable.generated.swift` file.

For example:

```swift
protocol FooProtocol { // sourcery: AutoMockable
func bar() -> Bool
}
```

:::info Manual generation
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

โš ๏ธ Grammar: "specially" should be "especially" in technical writing.

Suggested change
:::info Manual generation
or it cannot handle some closure types, especially in function's parameters. In such cases prefer


Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

โš ๏ธ Grammar: Missing "to" before "create". Should be "prefer to create the mock manually".

Suggested change
create the mock manually and remove the protocol's comment as `AutoMockable`.

There are some cases where the automatically generated mock does not cover the mock scenario we want
or it cannot handle some closure types, specially in function's parameters. In such cases prefer
create the mock manually and remove the protocol's comment as `AutoMockable`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

โ›๏ธ I would say "The protocol's AutoMockable comment".


:::

#### Custom annotations

Sourcery allows us to annotate different parts of our code to guide code generation. On top of this
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

๐Ÿ’ญ Clarity: This sentence is somewhat awkward. Consider rephrasing for better readability.

Suggested rewrite:

Suggested change
Sourcery allows us to annotate different parts of our code to guide code generation. On top of this
Sourcery allows us to annotate different parts of our code to guide code generation. Custom annotations have been added in `AutoMockable.stencil` to handle special cases.

custom annotations have been added in `AutoMockable.stencil` to handle special cases.

- **useSelectorName**: Method annotation used to indicate that the generated mocked properties need
to use the selector name instead of the short method name. This is specially useful when using
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

โš ๏ธ Grammar: "specially" should be "especially".

Suggested change
to use the selector name instead of the short method name. This is specially useful when using
to use the selector name instead of the short method name. This is especially useful when using

function overloading where we need the mocked names to also have the parameters names to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

โ›๏ธ Either "parameter names" (noun adjunct, my preference) or "parameters' names" (possessive of plural noun)

differentiate between the different mocked functions.
- **mockReceivedInvocations**: Method annotation used to indicate that we want to generate the
mocked property to store an array of the received invocations of the parameters passed each time
the function is called.

For example:

```swift
protocol FooProtocol { // sourcery: AutoMockable
func bar(fooParameter: String) -> Bool
func bar(anotherParameter: Int) -> Bool // sourcery: useSelectorName
func saveNumber(theNumber: Int) -> Bool // sourcery: mockReceivedInvocations
func annotateMultiple(fooParameter: String) // sourcery: useSelectorName, mockReceivedInvocations
}
```