Skip to content
Open
Show file tree
Hide file tree
Changes from all 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 @@ -74,6 +74,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 @@ -453,6 +453,54 @@ This makes it convenient to switch between these files or open them side-by-side
[ios version](https://github.com/bitwarden/ios/blob/main/.test-simulator-ios-version)), otherwise
tests may fail because of subtle differences between iOS versions.

### Mock generation

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, especially in function parameters. In such cases prefer to
Copy link

Choose a reason for hiding this comment

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

โ›๏ธ Grammar: "function parameters" (noun adjunct) is more natural than "function's parameters" (possessive).

Suggested change
or it cannot handle some closure types, especially in function parameters. In such cases prefer to
or it cannot handle some closure types, especially in function parameters. In such cases prefer to

create the mock manually and remove the protocol's `AutoMockable` comment.
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 `AutoMockable` comment.
create the mock manually and remove the protocol's `AutoMockable` comment.


:::

#### Custom annotations

Sourcery allows us to annotate different parts of our code to guide code generation. Custom
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 structure could be improved for readability.

Suggested rewrite:

Suggested change
Sourcery allows us to annotate different parts of our code to guide code generation. Custom
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.

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 especially 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: "parameter names" (noun adjunct, preferred) is more natural than "parameter's names" (possessive).

Suggested change
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 parameter names to

function overloading where we need the mocked names to also have the parameter names to
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
}
```

### Test plans

Test plans are organized in the `TestPlans` folder of the iOS repository. Each project has multiple
Expand Down
8 changes: 4 additions & 4 deletions docs/getting-started/mobile/ios/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@ sidebar_position: 1

1. [Xcode](https://developer.apple.com/xcode/) (using
[this](https://github.com/bitwarden/ios/blob/main/.xcode-version) version)
2. iOS & watchOS simulator runtimes installed
2. iOS and watchOS simulator runtimes installed
3. An iPhone simulator set up (check
[model](https://github.com/bitwarden/ios/blob/main/.test-simulator-device-name) &
[model](https://github.com/bitwarden/ios/blob/main/.test-simulator-device-name) and
[version](https://github.com/bitwarden/ios/blob/main/.test-simulator-ios-version) to make/run
snapshots)

Expand Down Expand Up @@ -61,8 +61,8 @@ sidebar_position: 1
$ cp Scripts/post-checkout .git/hooks/
```

Also, if the Xcode version installed mismatches the expected one you will receive a warning when
the script finishes like this one which can help troubleshooting.
Also, if the installed Xcode version does not match the expected version, you will receive a
warning, which can help with troubleshooting. That warning looks like this:

```
๐ŸŸก Xcode version mismatch!
Expand Down
Loading