taskwarrior icon indicating copy to clipboard operation
taskwarrior copied to clipboard

Renaming test files according to their language

Open mattsmida opened this issue 1 year ago • 3 comments

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 test and address any failures before submitting.

mattsmida avatar Apr 27 '24 02:04 mattsmida

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.

felixschurk avatar Apr 27 '24 04:04 felixschurk

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.

felixschurk avatar Apr 27 '24 04:04 felixschurk

I will leave this to the two of you for review - please @ me if you need the "merge" button clicked!

djmitche avatar Apr 28 '24 19:04 djmitche

Thank you @felixschurk and @ryneeverett for the feedback. I have made the requested changes:

  • test-namer directory is gone
  • Now using *.test.* instead of *.t.*
  • Updated documentation and supporting orchestration scripts

mattsmida avatar Apr 29 '24 16:04 mattsmida

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 avatar Apr 29 '24 22:04 felixschurk

@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:

ryneeverett avatar Apr 30 '24 00:04 ryneeverett

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.

felixschurk avatar Apr 30 '24 05:04 felixschurk

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.)

mattsmida avatar Apr 30 '24 18:04 mattsmida

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)

felixschurk avatar Apr 30 '24 19:04 felixschurk

@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.

felixschurk avatar May 01 '24 03:05 felixschurk

@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!

mattsmida avatar May 01 '24 16:05 mattsmida