Spyable as part of test target

[albertopeam]

I haven't made a POC but it looks like that the Spyable will be part of the app itself, I mean, it will become part of the IPA that will run on devices. Is it possible to do something like the next example to only add the spies to the test target?

@Spyable
extension ServiceProtocol {}

If you need help don't hesitate in contact :)

[Matejkob]

Hi there!

Thanks for starting this discussion! That's a very important subject. I've given it some thought during the design process. Personally, I wouldn't want to include the generated code in my main source code. Fortunately, macros generate code at compile time, so this code won't be visible in your git repository; you can't commit code generated by a macro to your repository (only usage of this code). This is a huge advantage for Spyable, particularly as in many of my projects where we've used Sourcery, we've often encountered issues with different AutoGenerated files in PR's, since not everyone enjoys running it every time they modify a protocol.

However, there is still one issue. Your auto-generated spy is visible from your source code, which means you could accidentally use it in production code. To mitigate this, during the design process of this macro, I decided to use internal modifiers to prevent accessing Spies from other targets. As we know, this requires the import {target_module_with_protocol} to be decorated with a @testable attribute. Ideally, as you suggested, it would be best to generate spies directly into the test target. Regrettably, to the best of my knowledge, this is not currently possible.

As for the proposed example, I'm afraid it's not going to work as expected. Using a macro on an extension of a protocol rather than the protocol declaration itself might seem like an elegant solution at first, but it's important to understand how macros actually work.

Macros are part of the preprocessor stage in the compilation process. During compilation, Swift expands any macros in your code before building your code as usual. They operate on the Abstract Syntax Tree (AST), which is a tree representation of the syntactic structure of the code. Macros themselves do not have any knowledge about the types, classes, or interfaces - they only have access to this plain textual structure.

Therefore, attaching a macro to an extension won't have the effect you're hoping for, because the macro won't know anything about the extended protocol. The protocol and the extension are separate entities in the AST and the macro wouldn't be able to connect them.

We could indeed utilize compiler directives, specifically the #if directive, to check whether the DEBUG flag is enabled or not. This way, we can include the spy code only when the app is built in debug mode for testing. When the app is compiled for a release, the spy code would be ignored and wouldn't be a part of the final IPA.

Here's an example of how this might look:

@Spyable
protocol Foo {
   func bar()
}
// expends to:
#if DEBUG
class FooSpy: Foo { ... }
#endif

This strategy should help us keep our production codebase clean while still maintaining the convenience of having test spies during our development process. Please let me know if you have any thoughts or further questions on this approach!

[albertopeam]

We could indeed utilize compiler directives, specifically the #if directive, to check whether the DEBUG flag is enabled or not. This way, we can include the spy code only when the app is built in debug mode for testing. When the app is compiled for a release, the spy code would be ignored and wouldn't be a part of the final IPA.

Do you plan to include it in next releases?

[Matejkob]

In the next few days, I am going to experiment with it a bit and we'll see how it works.

[SergeyPetrachkov]

The problem with 'if Debug' is that if you are building a debug build for your QA team or something like that, you'll end up with all the symbols in your binary. Unless the symbols stripping is in place. But anyway, it's worth investigating

[Matejkob]

If I'm not mistaken, in theory, you can also run your tests with configurations other than Debug, so this approach has a few downsides.

I find your suggestion, @SergeyPetrachkov, about using the #if canImport(XCTest) directive really instructive. I'll investigate it further.

By the way, if we decided to implement such a solution, I believe we could set up some sort of flag system to allow users to decide whether they want to use some restrictions in this context.

[SergeyPetrachkov]

Yeah, having this flexibility for end users would be great 👍

[ugoArangino]

@Matejkob Any updates on this toppic?

[Matejkob]

@ugoArangino sorry for such a late respond but I believe we have an update on the topic! For more information check-out this issue: #41

[Matejkob]

I believe PR #64 addresses the need from this thread.