[Bf-committers] Added the BlenderUnitTest (BUT) - so now what?
hewi at jupama.org
Mon Jul 11 11:08:18 CEST 2016
- I have created a git diff patch and uploaded this to the developer site
(tried the arc diff command, as explained here https://secure.phabricator.com/book/phabricator/article/arcanist_diff/
but that did not seem to do much)
- I have added reviewers whom might point me in the right direction of responsibles
- I will brosed the developer bug tracker to see if I can find an area off interest
- Not sure if there is an advantage of BUT over the gtests, it is just different. Assuming it is better to test more than not at all, I just carried on.
- I have tried to look at the gtest code but need to say it is quite obscure, for me anyway. It is written in c++, base on google test libs, and I can't really make sense out of it. Maybe if you guide me/us, I/we can build further on the gtest :)
What's the advantage of BUT over gtests which we've already have
On Fri, Jul 8, 2016 at 11:00 PM, Lukas Stockner <lukas.stockner at freenet.de>
> For code review, please upload the patch (generated by e.g. git diff)
> here: https://developer.blender.org/differential/diff/create/
> I don't really know who's responsible for Blender Unit Tests, but if you
> know who might be a decent candidate, just add them as a reviewer.
> As for buggy areas, a good approach there would probably be to just watch
> the incoming bugs on developer.blender.org. Alternatively, asking for
> bugs to solve in #blendercoders on IRC will certainly get a few answers ;)
> Am 08.07.2016 um 21:51 schrieb hewi jupama:
> > Ladies and gents,
> > Recently, I saw a new function was introduced in the BLI_rand file:
> "BLI_rng_get_char_n", so I said, hey, it is not been tested ... fair it is
> not the most important or difficult of functions but hey, you need to start
> > So I went out and into the source code, with following flow:
> > - downloaded blender git
> > - branched the 'BUT' :) (BlenderUnitTest)
> > - CMake changes: added the BUT_GLOBAL_DEBUG option, added the
> subdirectory, created the BUT library, linked it all together
> > - created subdir BUT with the .c and .h files
> > - Cmake generated a codeblocks project
> > - included the BUT.h header and introduced the BUT_testAll() function
> (in creator.c)
> > - created the BLI_rand.blenlib.source.blender.BUT.c file
> > - to actualy create the BUT_BLI_rng_get_char_n test function (that's
> what it was all about)
> > - included a desriotion in the BLI_rand.h file for the
> BLI_rng_get_char_n function
> > - included static testers for the BLI_rng_get_char_n function in the
> BLI_rand.c file
> > - reversed engineered the BLI_rng_get_char_n function slightly :)
> > - released the code unther GNU GPL v2 or later, (C) Blender Foundation
> > 1 - So what happens now, do I need to make a pull request, or do I
> generate the BUT branch on the developer site or ...? How can I show you
> the code?
> > 2 - Also, this effort will lead to feedback and insights, which I would
> really appreciate to receive here or off-line. But how can you actually
> review this code?
> > 3 - and also, for me most importantly, maybe you could indicate an area
> where the bugs are hard to crush, an area where you have trouble finding
> the solution, maybe I can then dig in to do some testing and possibly find
> the solution using a bit of reverse engineering?
> > The latter, I would find very, very cool!
> > regards, Hewi
More information about the Bf-committers