Renaming test files according to their language
Description
This PR updates the naming convention of the Python and shell test files to be consistent with the one used by the C++ test files. E.g., test_name.t becomes test_name.t.py or test_name.t.sh.
Additional information
- [x] I changed C++ code or build infrastructure.
Please run the test suite and include the output of
cd test && ./problems.
Failed:
Unexpected successes:
Skipped:
Expected failures:
lexer.t 4
- [x] I changed Rust code or build infrastructure.
Please run
cargo testand address any failures before submitting.
I do not see the need for having the test_namer folder in the repository.
As if then by now when someone creates a new test one should adhere to the coding convention.
Other than that it does look good so far. But on another notice, currently the python tests are not run, see https://github.com/GothenburgBitFactory/taskwarrior/issues/3351#issuecomment-2043664761.
Meaning currently the output of ./problems is not reliable or only counts for the unit tests.
I will leave this to the two of you for review - please @ me if you need the "merge" button clicked!
Thank you @felixschurk and @ryneeverett for the feedback. I have made the requested changes:
-
test-namerdirectory is gone - Now using
*.test.*instead of*.t.* - Updated documentation and supporting orchestration scripts
It does look good. :)
Due to the update in #3387, we also do need to update the CMakeLists etc. This was at the state where you forked not yet implemented. I did not want you to go thru that hassle and therefore rebased and updated it, however I am unable to push to this PR directly.
Specifically I mean https://github.com/felixschurk/taskwarrior/commit/f8f72a71769e8851e76b0d7907dc2e91ceee6e30 and https://github.com/felixschurk/taskwarrior/commit/18802ecac0c529a5646c338911ec039fd02a3dc5, you can see in my fork of your fork https://github.com/felixschurk/taskwarrior/commits/rename-test-files-3404/.
I think one is only able to push to a PR if it is allowed when creating the PR and one is a maintainer of the project, but that I do not know how it is here. @djmitche do you know why it might be not working?
Nevertheless, in order to keep going you could add my for as a remote, pull down the two commits and incorporate them into your branch which you can then push up again. Or you can also copy the changes into the files (might be the easiest).
@felixschurk You could make a pull request directly against @mattsmida's rename-test-files-3404 branch. IMO that's generally a better strategy than pushing directly.
Edit: Or maybe you can't and that's what you were saying. I tried but his repo doesn't seem to be a valid base repository in github UI. :man_shrugging:
Yes, I think that would be a good thing. But I am also unable to create a PR against @mattsmida fork.
But generally it seams to be available, e.g. I could create a PR against @ryneeverett's fork.
Hi @felixschurk -- I believe this is ready now. The two commits https://github.com/felixschurk/taskwarrior/commit/f8f72a71769e8851e76b0d7907dc2e91ceee6e30 and https://github.com/felixschurk/taskwarrior/commit/18802ecac0c529a5646c338911ec039fd02a3dc5 have been incorporated into this PR. I did the "copy" method that you suggested in the last sentence of your comment: https://github.com/GothenburgBitFactory/taskwarrior/pull/3407#issuecomment-2083798120.
(My apologies for configuring my fork such that PRs could not be created against it -- I think that was the default setting that I left unchanged when making the fork.)
Hei, thank you a lot for the work. It does look good.
Currently I am only a bit baffled as here the CI did not run, but I think that maybe a maintainer needs to start it manually. In my branch they did run sucessfully, so that should not be a problem.
@djmitche
- [ ] Could you please run the CI?
- [x] Link the issue to this PR?
When it is successful, the PR is ready to be merged :)
This PR will close #3404. (Does not work unfortunately for linking it)
@mattsmida As djmitche pointed out yes, there are the CMakeLists missing in the folders. In order to have them best would be to update your develop, and rebase/merge the changes into this branch. Then the CI should run.
You can also verify it locally if it is building, in the current state it fails to generate the build files.
@djmitche @felixschurk I followed Felix's advice:
In order to have [the CMakeLists] best would be to update your develop, and rebase/merge the changes into this branch. Then the CI should run.
Now the CI is running and I'm seeing that there are no longer conflicts between this branch and the base branch. So I believe it's ready to merge. Thank you both for bearing with me!