Skip to content
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

Ability to store approval files under different folder #2

Open
mzagar opened this issue Apr 22, 2013 · 11 comments
Open

Ability to store approval files under different folder #2

mzagar opened this issue Apr 22, 2013 · 11 comments
Assignees

Comments

@mzagar
Copy link

mzagar commented Apr 22, 2013

I'd like the ability to store generated approval files under different folder and not strictly in the folder where my test source code is located.

For example, when using maven-type projects, my source files are located under PROJECT/src/test/java/some/package and I'd like approval files to be generated under PROJECT/src/test/resources/some/package. This helps keeping the test source folder clean and free of lots of approval files, especially when there are lots of test classes with lots of tests using Approvals.

I will submit a pull request with my proposed solution to this issue.

@nikolavp
Copy link

nikolavp commented Sep 1, 2014

My more modern approval java port at (https://github.com/nikolavp/approval) can archieve this with something I call PathMappers. Actually this is the main usecase for them, you can find more information in the docs

@talios
Copy link

talios commented Aug 19, 2019

Was this PR ever made? Or included in this non-fork?

@beatngu13
Copy link
Contributor

I believe @LarsEckart's PR #100 for further options is a step in this direction. The to-do list now also contains "Options for file path":

https://github.com/LarsEckart/ApprovalTests.Java/blob/6eaae958b2ec66d7d4a79295e4ec93655ca0f2eb/todo.txt#L3

Ideally, this can be configured globally viaa properties file or something similar. Otherwise, one would have to set this for each verify I guess?

@LarsEckart
Copy link
Contributor

Triggered by another PR, we updated documentation as this feature is already available: https://github.com/approvals/ApprovalTests.Java/blob/master/approvaltests/docs/Configuration.md#package-level-settings

Does this help?

@beatngu13
Copy link
Contributor

Thanks for the hint @LarsEckart, works for me!

Side note: Since PackageSettings field names are upper camel case, some IDEs might create warnings for not following Java naming conventions. Also the class name may confuse others when looking at the code base / tests because it is not linked to ApprovalTests.

For a future release, instead of:

public class PackageSettings {
    public static String ApprovalBaseDirectory = "../resources/";
}

Maybe you want to consider something like:

class ApprovalTestsConfiguration {
    static final String APPROVAL_BASE_DIRECTORY = "../resources/";
}

✌️

@talios
Copy link

talios commented Apr 21, 2021

Could we take this one step further with package level annotations?

@ApprovalBaseDirectory("../resources/')
package com.foo;

which gets stored in package-info.java - see https://puredanger.github.io/tech.puredanger.com/2007/02/28/package-annotations for some details.

@LarsEckart
Copy link
Contributor

We didn't know about package level annotations, it looks interesting!
Tonight we didn't get to it but maybe next week :-)

@talios
Copy link

talios commented Feb 25, 2022

@LarsEckart did @ApprovalBaseDirectory make it into approval tests?

@LarsEckart
Copy link
Contributor

@talios sorry, we didn't get to it and then it disappeared from my radar. lately we were spending time on our pipelines but I hope to soon tackle our open issues here again more actively.

@LarsEckart LarsEckart self-assigned this Feb 25, 2022
@talios
Copy link

talios commented Feb 25, 2022

@LarsEckart All good - I'd totally forgotten about it til I ran into some code locally references this ticket ;)

@talios
Copy link

talios commented Feb 21, 2025

I wonder if anything further for @ApprovalBaseDirectory came about, lately I've been getting hit with #370 often, and using something like package level annotations would be useful.

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

No branches or pull requests

5 participants