-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Added simple unit test sample for demonstration #4154
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please split the patches into smaller ones, the test itself looks fine for me.
Thanks a lot for this, that was so so so much needed ! I will let @cryptomilk do the review. |
FYI: I will give a talk about cmocka at devconf.cz this weekend. I guess it is recorded and will be available next week. |
That's a wonderful step forward! Thanks a lot, for sure this will help dt to avoid regressions and will make big refactoring less scary! Looking forward to have this in action ! |
I've checked what the issue is and it is rawspeed which uses |
Not sure if you are right. My code is listening to BUILD_TESTS and not BUILD_TESTING. But I just realized that it works when I include cmocka in the base CMakeLists.txt. |
See https://cmake.org/cmake/help/latest/command/enable_testing.html BUILD_TESTING is forced to OFF. |
I see. To me, cmake is still very new. Do you have any suggestion on how to fix this issue? Current state of this PR is working fine but I think it only works by chance and it is not a proper solution (cmake should probably be included in ./src/CMakeLists.txt and not in ./CMakeLists.txt, right?). |
We need to change the variable in rawspeed to BUILD_RS_TESTING first. It shouldn't use BUILD_TESTING. |
Ok, I think I understand now. I gave it a try and made a pull request for rawspeed: darktable-org/rawspeed#223 |
Please, please. When writing a commit message, don't just state "we need to do XYZ". |
Thank you, @LebedevRI, your comment made me re-think again. As far as I understand now, the BUILD_TESTING is set to Off for rawspeed - or more precisely: set to Off by the darktable build system in src/external/CMakeLists.txt. But it is done "hidden" - i.e. the original value of BUILD_TESTING is stored at the beginning and reverted at the end. Thus, I think the pull request in rawspeed is not needed. Also, I found out that my first commit (fixing the include of ThreadSafetyAnalysis.h) is not needed anymore with the current implementation. My current code is working fine on my machine (retried both cases with/without tests and deleted the buld dir each time before). I will update this PR. @cryptomilk could you please have a look again? Does it make sense to you as well? |
Note that it is darktable's file, not rawspeed's.
Yep, at least that is the intent. |
Yep, updated my above comment |
Ok, it looks like BUILD_TESTING is not a problem. I'm on the train home and finally tracked it down. See here: https://github.com/cryptomilk/darktable/tree/master-fix
|
@burrima Do you want to push my branch here? |
@cryptomilk yes sure, thank you very much for your support. Honestly I cannot follow what issue you are addressing with the extra commits. On my PC I get (almost) exactly the same output (without your fix):
Why do you get "test_test_filmicrgb" (note the double-"test_")? |
I've already fixed that (double test_). I've split the code a bit more and include(CTest) needs to be included in the main CMakeLists.txt else it doesn't work. |
Did you get my latest code updates to this branch? - I already have the CTest included in the topmost CMakeLists.txt. The reason why I am asking is because I see that you still have an old state of test_fimlicrgb.c in your branch. I re-formatted it with clang and removed the ugly looking I could include your 2 fixing commits before my commits if you wish so (though maybe a separate pull request for them would be more clever since I think the code is not related). But at the end, your voice has more power since you are in this project way longer than me :-) BTW: how was your presentation? I looked through your slides on the devconf.cz site and found them very informative. |
Can you merge my work into yours? :-) |
Yes, I'll do that. Sounds like the best strategy for me as well :-) Please give me some time since I'm going for dinner now. |
Ok, done. BTW: your branch |
@burrima Could you add cryptomilk@c19aba4 |
Please rebase on master and repush tomorrow. New docker images with cmocka should be available then ... |
Ran docker on my ubuntu 18.04 pc. Then built dt inside the docker image. Tests then were running fine... |
@LebedevRI Roman, I'm not really familiar with TravisCI, do you have an idea why the tests fail with "Permission denied"? @burrima Maybe also print:
|
@burrima Try with cryptomilk@7447782 |
That's it. https://github.com/cryptomilk/darktable/commits/master-cmocka works :-) |
This will work once we just allow to run darktable in the build dir. Dave is working on this.
- based on cmocka (https://cmocka.org) - thus, it needs to be installed before building. On Ubuntu 18.04: "apt install libcmocka-dev" - build darktable with option -DBUILD_TESTING=ON - then run `make test` Signed-off-by: Martin Burri <[email protected]>
This commit integrates function mocking with cmocka. The code is still very empty and I will continue to work on this. Signed-off-by: Martin Burri <[email protected]>
@TurboGit This is good to go! |
@burrima @cryptomilk : Maybe I expected something else so I'm not sure to understand what is provided here. Is that only unit test on the code ? What I thought was worked on was a way to give a source image, some actions like an XMP apply it and check that the output is consistent what what is expected (fuzzy comparison with the target image). Is that covered here ? Whatever the answer to the question above I think we want a README in the test directory explaining how to add a test ? I did not find the high level description about this and I do feel this very important as adding tests is something we want to see encouraged as much as possible. |
@TurboGit This is code for function unit testing of the darktable code. I will add methods to create very simple test images in a next pull request. Thus, process() methods of modules can be tested. But unit-tested. So, no function testing as you described it. A README is underway as well. Together with already implemented tests. |
@TurboGit feel free to look at my work in progress. But please be gentle, it's really still under progress :-) https://github.com/burrima/darktable/tree/test_filmicrgb |
@TurboGit Pascal, what you expected is called integration test, this is unit testing :-) Martin already found bugs in filmic rgb writing unit tests for it :-) |
Hi @TurboGit, may I kindly ask what makes you hold back this pull request? Besides of documentation (which I promised to deliver in my next pull request) what else is missing or making you struggle? - Or do you just need more time to review? I'm not in a hurry at all though it would be a great satisfaction to me to see my first real contribution to darktable going in. Best regards, Martin |
@burrima : Just time and priorities. I've been working on integrating the new iop-order and working on big performance degradation. This PR is certainly a nice contribution, I just need more time to review and merge. |
Sure, no problem, take your time. I was just wondering if you are expecting more from my side. |
@burrima : I had a look and the code as-is is ok to me. I'm not really sure how easy or feasible it will be to create serious test. BTW, is that to test only iop code or also the other parts of dt ? And in this case how all this will interact with the database (many routines are doing SQL) ? The pixel-pipe ? Are all those parts covered here ? If it is only iop I think it is "simpler" and still just for this it will be nice to have in. I have then nothing against merging this, still please give me some feedback regarding my questions above. Thanks. |
@TurboGit thank you very much for the review and your feedback. From my side, I will focus on the iop for a good while. But there is generally nothing against writing unit tests for other parts. The nice thing about cmocka is that you can "mock" (https://en.wikipedia.org/wiki/Mock_object) functions, meaning that you can "overwrite" functions that are called by the function-under-test to mimic different behavior. Thus, you can break dependencies (e.g. to the database etc.). Unit tests are in my eyes just a start - there is definitely the need for more automated testing (e.g. when it comes to GUI interaction). |
Ok, so let's move on ! I'm eager to see unit test be added :) Thanks for the work! |
@TurboGit cool, thank you very much! Unit tests are in the pipe :-) |
Pull request contains 2 commits that were made earlier by @cryptomilk - thank you very much for your help!