rename test fixtures (test data) => test artifacts

[ltalirz]

The name "fixtures" is currently used both for the pytest fixtures and
for test data in tests/fixtures, such as AiiDA export files.
This is confusing and makes searching in the codebase unnecessarily
difficult.
Here, we rename the test data folder to "artifacts", which I believe is
a more common term for this type of data.

[codecov]

Codecov Report

Merging #4219 into develop will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #4219      +/-   ##
===========================================
- Coverage    79.09%   79.08%   -0.00%     
===========================================
  Files          468      468              
  Lines        34642    34642              
===========================================
- Hits         27396    27394       -2     
- Misses        7246     7248       +2     

Flag	Coverage Δ
#django	72.71% <ø> (-<0.01%)	⬇️
#sqlalchemy	71.90% <ø> (-<0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
aiida/engine/daemon/client.py	72.42% <0.00%> (-1.14%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f23078e...6219600. Read the comment docs.

[sphuber]

I am not sure that the interpretation of artifacts is correct. An artifact is usually an object that is produced as the result of running a test. It is not the data that is required to run the test. Instead, fixture is exactly defined as "that what is necessary to construct the context in which a test should be run". This includes pieces of data that need to be loaded.

[ltalirz]

I see, the Ruby definition you linked would certainly apply.

As you mention, the more generic definition seems to be (wikipedia )

A software test fixture sets up a system for the software testing process by initializing it, thereby satisfying any preconditions the system may have.

I.e. it applies directly to the pytest fixtures, and can also include test data.

I agree that "artifacts" is probably not a good word for test data either, but I do feel that it would be useful to be able to differentiate between the pytest fixtures and test data (the reason I did not name the folder "data" was that this would again clash with AiiDA terminology), so that if somebody talks about "the fixtures" we know what they mean.

Anyhow, if we aren't able to find a good, more specific name for the content of this folder, I'm also fine with closing this PR.

[sphuber]

You said your main reason for wanting to change the name is for searching reasons? If you are searching in the code, the filenames won't show up, no? And if you are looking in filenames: there are not that many files/folders that include the word fixture

[sphuber]

Have you had any feedback on this in person @ltalirz since the group meeting? If not, I would vote to close this.

[ltalirz]

@sphuber The suggestions in the AiiDA meeting notes were static and test_data.
static is very commonly used in web applications - not sure how often it is used in tests but I think it would actually fit quite well. What do you think?

Besides changing the name, the PR also added a variable for the path to the static resources, removing a couple of duplicated/hardcoded relative paths.
Not really important, but something I could fix in any case.

[sphuber]

I think test_data would actually be confusing, as it may confused with testing our data module or Data class. Anyway, to be honest, I really still don't see a real reason for changing this and find we are now trying to hard to find a way to change it. I really think the name fixtures is more than appropriate for what this folder contains. They are actually what a fixture is supposed to be, a piece of data or an object that is solely there to be setup at the beginning of a test to setup the environment. I don't think pytest has the monopoly on that term to only have it apply to functions decorated with pytest.decorator. Term static would also not improve things because now we are importing a term that is never used in the testing context but in web applications.

[CasperWA]

I think test_data would actually be confusing, as it may confused with testing our data module or Data class. Anyway, to be honest, I really still don't see a real reason for changing this and find we are now trying to hard to find a way to change it. I really think the name fixtures is more than appropriate for what this folder contains. They are actually what a fixture is supposed to be, a piece of data or an object that is solely there to be setup at the beginning of a test to setup the environment. I don't think pytest has the monopoly on that term to only have it apply to functions decorated with pytest.decorator. Term static would also not improve things because now we are importing a term that is never used in the testing context but in web applications.

I must admit that I am quite motivated to change the name of folder as well to not name clash with the pytest concept. Simply because it can be confusing, especially since the fixtures we're actually using are not even located in the tests folder, but under aiida.manage.tests. Hence, one may think the fixtures folder under tests should indeed contain pytest fixtures, because they are unable to find the actual fixtures ...
I know it sounds a bit sought. But the whole setup induces a bit of confusion, and having this folder be named differently might mitigate some of that confusion for new and old aiida-core developers.

That said, I will throw my vote behind changing it to static. Even though this is not a web-application (minus the REST API), it is understood what is meant from the context and it doesn't name clash with other parts.

[ltalirz]

I'll write to the guys involved in the coding days to give a vote to the three options - please vote with thumbs up/down

[ltalirz]

Option 1: Keep name tests/fixtures

[ltalirz]

Option 2: Switch to tests/static

[giovannipizzi]

What is the third option you mention? Personally, I don't mind either changing it to static or keeping as it is, I don't find it a problem either way.
Just to provide an option 3 myself, though, what about data_fixtures? feel free to vote below this comment if you like it. Otherwise, ok for me to go with whatever most people prefer (and in case of a tie, probably I'd keep as is?)

[ltalirz]

What is the third option you mention?

Sorry, I should have said two options.
There was another option artifacts that i had in mind but I think @sphuber made reasonable arguments against it.

[CasperWA]

I'll just add option 3 (from the now closed #2817): tests/archives

[sphuber]

I would not go with tests/archives because as you noticed yourself, it does not contain exclusively archives. However, given that static now has three upvotes, let's just go with that.

[sphuber]

@ltalirz if you can change this to use static I will approve and merge

[ltalirz]

@sphuber Ready for review

[sphuber]

All good, thanks @ltalirz