-
Notifications
You must be signed in to change notification settings - Fork 51
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
Use namespace instead of class Approvals #5
Comments
Thank you for the recommendation. If I understand correctly, all the classes and namespaces in Does that mean that |
We are intending to introduce a consistent namespace to all of the contents of ApprovalTests/ soon - likely in the next week... We may also add a second layer of namespaces, e.g. something like ApprovalTests::Writers::StringWriter... Comments on this would be appreciated.... |
I've started experimenting with this in CLion, trying to find an efficient workflow for moving all our code in I'll record here what I've found - and ruled out. |
Try 1 Just use Move refactoring in CLion - gets paths of headers wrong, so won’t compile - tried a script to remove the wrong lines - too much faff. Example build error:
|
Try 2 In CLion, move all headers to top level of project, then use Move in CLion. |
Try 3 Go back to use Move refactoring in CLion - gets paths of headers wrong still, so work around that by editing CMakeLists.txt to temporarily get builds working with the new, wrong #include paths - with the intention to revert the CMake edit later, and delete all the wrong #includes in one go. This was the first change in ApprovalTests/CMakeLists.txt - which was needed when refactoring headers in ApprovalTests - when we move on to the sub-directories, like -target_include_directories(${PROJECT_NAME}
- INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/..)
+target_include_directories(${PROJECT_NAME}
+ INTERFACE
+ ${CMAKE_CURRENT_SOURCE_DIR}/..
+ # Temporary extra paths,
+ ${CMAKE_CURRENT_SOURCE_DIR}/
+ ) This went well, albeit slowly on a fast Mac, until I spotted that CLion was making needless edits to std::shared_ptr - changing it to std::__1::shared_ptr - same for std::vector. These were hard to spot when viewing diffs, due CLion indenting the code that was moved to the namespace. |
Try 4 Start again, as in previous step, but try to change CLion’s settings so that, for now, it doesn’t indent when adding namespace - so it should be easier to spot any extra edits that it makes during these refactoring steps. |
caused by CLion's Move refactoring not recognising headers already included via relative paths. I'll revert this later, and remove all the incorrectly added #include lines, when we have finished the namespace addition. Issue: #5
Status I ended up finishing this off by making the edits to headers by hand, then fixing build failures. It was faster than waiting for CLion's refactoring. The changes on the namespaces_experiment branch show the progress I made on this. (Click on the "Files Changed" tab to see the differences". I've minimised the changes, like not changing indentation, so that this work can be reviewed more easily.) Basically, everything in the library is now in the namespace ApprovalTests. We talked about adding sub-namespaces like I did this before rearranging the files in the library, to not get under the feet of someone who may possibly offer us some code improvements... Remaining code to review About the only files not fully updated are the Catch2 and Doctest integrations. We should discuss those. Okra integration I also spent about an hour looking at setting up a test for the Okra integration - and then found that it has not compiled for some time because of changes we made in ApprovalTests.cpp. But more significantly, it didn't build against the version of Okra.h from the time when this integrated in to this project. I searched all of github for uses of the ApprovalTests.cpp/Okra integration, and there were none. I've sent @JayBazuzi a message on Twitter to see if he wants to pair on it, but right now my feeling is we should probably just archive the Okra integration code, since no-one has logged a bug that it has been broken for some time. Other Comments It's possible that some of the They are harmless, and I'm not worrying about the, now. |
I've updated the docs too, on the branch, to give a sense what the code looks like now: We might want to shorten lines in the first example in the above. The above does show the repetition - anyone who cares can do |
I don't mind if you break Okra, because I have epsilon users. One reason you might want to keep Okra working is that have Approval Tests work with multiple frameworks helps you know your integration points are sufficiently generally... But that's up to you. |
Thanks Jay, the thing is more that, as far as I can tell, the ApprovalTests integration has never worked, and I can’t tell how to fix it. |
This is now done. |
All classes should be put inside namespace. And the class
Approvals
should be removed since it is just a collection of static functions. They should be free functions inside the namespace.The name of the namespace should be ideally
ApprovalTests
. Downstream users would then useApprovalTests::verify(...);
The text was updated successfully, but these errors were encountered: