Skip to content

Disable filename counter #429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
h0shy opened this issue Feb 11, 2021 · 5 comments
Closed

Disable filename counter #429

h0shy opened this issue Feb 11, 2021 · 5 comments

Comments

@h0shy
Copy link

h0shy commented Feb 11, 2021

Is there a way to disable the counter at the end of the filename? We use the iOS version in the end of the name and to have .1 after each name is confusing. Any help would be much appreciated :)

@odisei369
Copy link

You could add named: parameter. Then library will not add this counter at the end of a file.

Example:

assertSnapshot(matching: view, as: .image, named: "my_view")

I hope it helped and we could close the issue.

@dafurman
Copy link

dafurman commented Jul 6, 2021

With the following example:

class MyViewControllerSnapshotTests: XCTest {
    func testLayout() {
        assertSnapshot(matching: MyViewController(), as: .image)
    }
}

Using "my_view" in a test would result in the following file name:
MyViewControllerSnapshotTests/testLayout.my_view.png
I think I'm in the same situation as @h0shy, where I'd really just be happy with a parameter or static var that disables the counter / suffixing, to have the full file path be: MyViewControllerSnapshotTests/testLayout.png.

I usually try to have one test correspond with one snapshot, so the simplest naming scheme for me would be to have the snapshot images match the test names, without adding any suffixes.

@stephencelis
Copy link
Member

Hi @dafurman! Thanks for the PR. I'm going to close this issue in favor of tracking the problem there, where we can discuss things further.

@Deco354
Copy link

Deco354 commented Jul 15, 2023

@stephencelis The fork containing this PR has been deleted. Can we reopen this issue?

@dafurman
Copy link

dafurman commented Jul 15, 2023

Yup, +1 to the issue being reopened or us following up on the PR. I mistakenly closed that PR while cleaning out some of my Github repo forks. I forgot about that PR. I recreated it here: #747

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants