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

There should be one logic/api that takes care of all files to be stored during/after test execution #157

Closed
MatousJobanek opened this Issue Sep 18, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@MatousJobanek
Contributor

MatousJobanek commented Sep 18, 2017

Extend/Change LocalStorage class to have two options/methods:

  • duringExecution - to store files nedded (storable) only during execution - in ${base.dir}/.smart-testing directory
  • afterExecution- to store files to be persisted also when the test finishes - in ${base.dir}/target/smart-testing

duringExecution has two options:

  • temporary - containing temporary/working files that will be removed after the build finishes (currently it is named execution but I would change it not to confuse with the duringExecution name)
  • reporting - containing report related files - after the test execution, the dir will be copied to ${base.dir}/target/smart-testing

afterExecution has only one - reporting which is the very same directory as that one from the previous part with the difference, that it is immediately stored in the target dir.

The usage the looks like:
to store scm changes:

new LocalStorage(currentDirectory)
                .duringExecution()
                .temporary()
                .file(SMART_TESTING_SCM_CHANGES);

to store report:

new LocalStorage(baseDir)
                .afterExecution()
                .reporting()
                .file(REPORT_FILE_NAME);

As you know - choosing the class/method names is one of my weaknesses :-). If you have some better names, I'm open for any change.

@MatousJobanek

This comment has been minimized.

Show comment
Hide comment
@MatousJobanek

MatousJobanek Sep 18, 2017

Contributor

This can be also considered as an attempt to prepare local storage for one API that will take care of both - storing locally and in a cloud. That is also the reason why I'm trying to make it unified across the whole project.

Contributor

MatousJobanek commented Sep 18, 2017

This can be also considered as an attempt to prepare local storage for one API that will take care of both - storing locally and in a cloud. That is also the reason why I'm trying to make it unified across the whole project.

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 18, 2017

Member

Good idea @MatousJobanek. We need to start improving the code base.

the chain of methods is a bit unclear for me, so I would propose a slight change: how about changing reporting() into toReporting()?

Member

bartoszmajsak commented Sep 18, 2017

Good idea @MatousJobanek. We need to start improving the code base.

the chain of methods is a bit unclear for me, so I would propose a slight change: how about changing reporting() into toReporting()?

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