Okay, I'll take a look into it. The only think that I may be worried about is the license, I'm not sure how that would work for unit testing, so I'm not sure if the BSD license would be comparable with a GPL project.
~Leif Andersen ---------- That was easy: http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton On Wed, May 5, 2010 at 04:23, Keir Mierle <mie...@gmail.com> wrote: > Congratulations Leif for having your proposal accepted! > > I thought I would drop in to plug the Google Test unittesting framework. > Yes, it's C++, but it has some features like automatic test registration > and > concise syntax (among others) that make it superior to the pure C > frameworks. Furthermore, I am a committer on the project and offer my > support. I will be available for the duration of GSoC. I can also help with > build integration, as I've integrated Google Test with several projects. > > http://code.google.com/p/googletest/ > > I'm happy answer any questions. > > Keir > > > On Thu, Mar 25, 2010 at 7:29 PM, Leif Andersen <leif.a.ander...@gmail.com > >wrote: > > > Hello, I am interested in participating in this years GSoC project. In > > particular, Unit testing. An area that I though Unit tests would be good > > was the API, but I'm very open to suggestions of any type. I have > attached > > a prototype of my proposal, if anyone is willing to look at it, and give > > constructive feedback, that would be greatly appreciated. I am likely > > going > > to change the bio at the end, as by the time Google will start accepting > > applications, I will be done with the current projects I mention. > > > > Again, thank you for your feedback. > > > > *Development of Unit Tests for the Blender 2.5 API* > > > > > > *Name* > > > > Leif Andersen > > > > > > *Email/IRC/WWW* > > > > Emain – > l...@leifandersen.net/leif.a.ander...@gmail.com/tbol3...@gmail.com > > > > IRC – Leif/LeifAndersen > > > > WWW – http://leifandersen.net > > > > > > *Synopsis* > > > > * *Unit Testing is a very powerful tool used to determine the accuracy of > > code components. While it is not generally used to test how various > > desperate components of a project interact with each other directly, it > can > > be used to make sure that individual components are working properly, > even > > when components from different areas of the project are changed. For > > smaller > > projects, and for components that are directly viewable to the user, this > > is > > not a necessity. If there is a bug, it is directly viewable. However, for > > larger projects, especially to portions of it that are hidden to the > user, > > this become very important. Unit testing helps developers of the project > > determine which component the problems are coming from. > > > > The goal of this project is to provide Unit Tests for all of the > underlying > > parts of the Blender API. Furthermore, if time permits, this project will > > attempt to clean up the more stable portions of the Blender API, and > expand > > upon the current state of Blender development documentation. > > > > > > *Benefits to Blender* > > > > According to the Blender code base,i <#127984db651a29d1_sdendnote1sym> > > there > > currently is no main section for Unit Tests, leaving any tests in the > code, > > to be embedded within the files themselves. Furthermore, the main way to > > determine how files are linked together, is to look at the makefiles > > themselves, and to browse through the Blender code base. While this can > be > > a > > little daunting to new developers, the main problem is that this makes it > > harder for regular contributers to test every component to make sure that > > their slight changes to the code doesn't break anything. > > > > This means that the current developers of Blender, especially the ones > > working on the API, can spend more time making the code better, and less > > time searching to find where their bugs are hidden. This is especially > > useful for Blender with it's larger emphasis on the API. With lots of > > development going on in that area, unit tests will be a valuable asset to > > the Blender code base. > > > > > > *Deliverables* > > > > By the end of this project, there will a simple set of tests that > > developers > > can run to ensure that their modifications to the code did not change > > anything major. Furthermore, these tests will give robust information as > to > > where the error occurs, to aid in the removal of any bugs. Finally, these > > tests should be reliantly fast to run, and be built to be tested on both > a > > modular, and holistic level. That way the tests can be run often by the > > developers, if they so choose to, but have the ability to perform all of > > the > > tests with a simple button, when needed. This is useful so that the > > developer need not completely recompile Blender, or the current module > > being > > worked upon, while the work is done. Which should increase the speed of > > development. > > > > These tests will be placed in their own folder, or possibly, spread > > throughout the code based delimited from the rest of the code. > > Alternatively, the tests could be stored in a different section > altogether > > outside of the main blender svn folder. However, it would be useful to > get > > any changes made to the tests, whenever a developer gets the latest code > > base. > > > > These tests can be run either as the developer works on the project, or > it > > can happen as any new patches are committed into the code base. > > > > > > *Project Details* > > > > CTestii <#127984db651a29d1_sdendnote2sym> is a powerful tool set which > can > > be used for generating test files. This is especially useful as blender > is > > already using CMake as an option to compile blender with. CDash can be > used > > as a straightforward front end, so the programmer can easily see the > > results > > of the tests. > > > > The first phase of the project is to create the Unit tests. They should > > test > > the API for everything reasonably conceivably thrown at it, even if it is > > an > > invalid parameter. This is important so developers, especially plugin > > developers who are still new to the API, will get useful information back > > when the put improper parameters into the function. The tests will not be > > compiled together into a simple set of tests during this phase. Also, > > during > > this phase, the tests will likely exist outside of the main trunk. > > > > The second phase is to incorporate all of the tests into a concise > package, > > to make it easier for developers to use. CDash will be used to make > > everything more readable. At this point, the tests will be usable, and > > should compile successfully. However, they won't necessarily be stable, > and > > may change if better, more accurate, or more efficient tests are > > discovered. > > These tests may be included in a separate blender/tests/ folder, or, as > > suggested on the CMake website,iii <#127984db651a29d1_sdendnote3sym> the > > tests could be set up to run whenever a new commit has been made. > > Alternatively, if the Blender Community does not believe that they wish > the > > tests to be run on Blender's Servers, CDash hosts a free testing > > environment, which can be temporarily for testing. However, using > Blender's > > Servers will allow for developers to get feedback, and as such, send > > feedback for requested features, before the completion of the project. > > > > The third phase of this project will be do document everything. While the > > development workflow for blender will be nearly identical to that of what > > it > > was before, with the option of testing your code, the current state of > > documentation for new developers could be improved. While not entirely > > pertinent to core developers, it is particularly useful for new plugin > > developers, who aren't interested in learning every internal piece of > > blender, but just want to develop a plugin that suites the piece of art > > that > > they are working on at the moment. Possibly, several tutorials explaining > > the components of the API could be generated, similar to Ira Krakow's > > Blender 2.50 Python tutorials.iv <#127984db651a29d1_sdendnote4sym> > > > > At this point, the main portion of the project should be completed. Any > > remaining bugs will be dealt with, along with code cleanup, to make it > > easier for the tests to be expanded upon as the API changes, and grows. > If > > not done so, the tests should be incorporated into the main blender code > > base, or set up to run either nightly, or as a new commit is made. > > > > > > *Project Schedule* > > > > * *Note that other then the start and end dates, these dates are > > predictions > > as to how the Blender Foundation would like me to allocate my time. If > > requested, I will be happy to change the dates for each of these phases, > or > > possibly even swap their positions, to spend more time on different > > segments > > of the project. > > > > I already understand portions of the blender code base and a fair chunk > of > > the Python API. Unless a catastrophe happens, I should be familiar with > the > > Blender code base by the May 24 start date. In fact, my last final is two > > weeks before that, as such, I hope to have the proper CTest environment > set > > up, and to have started creating several preliminary tests by May 24. > > > > >From May 24 to June 20 is phase one. I hope to take the preliminary > tests > > created before May 24, and turn them into rigorous test suites. By this > > point, there should be no serious > > > > >From June 20 to July 15 is phase two. I hope to take the tests suites, > and > > concatenate them into a fairly useful development tool. At this point, I > > hope to have many developers try the tool, and submit further requests > for > > tests that went under the radar in phase one. > > > > >From July 15 to August 16 is phase three. I hope to document the whole > > process, along with improving the documentation of the API itself. > > Furthermore, I will spend any extra time documenting other forms of > > development that is lacking details, particularly relating to plugin > > development, or new developers documentation. > > > > I may spend a week during the first part of July on vacation. I will > > continue to work on the code during this week. However, due to limited > > internet connectivity, communication will have to be limited to daily > email > > that week. > > > > In short, I will have no work or school over the summer. Per request, I > do > > not intend to take any summer classes, unless I'm explicit told that I > can. > > Even then though, it would only be one differential equations mathematics > > class. The only work that I have done is freelance tutoring. However, as > > the > > majority of schools in this area will be out, I will not be spending any > > time on that. > > > > > > *Bio* > > > > * *I am a 19 year old computer engineering and mathematics student > studying > > at the University of Utah. I first started programming in 2001 when my > > parents bought a copy of Interplay's Learn to Program > > Baisc,v<#127984db651a29d1_sdendnote5sym>a CD designed to get > > adolescence interested in computer science by making > > simple video games. Still interested in video games, I then went on to > try > > out Mark Overmar's Game Makervi <#127984db651a29d1_sdendnote6sym> (now > > controlled by Yoyo Games). There, I created several platformers, and > space > > shooters. Also interested in multimedia and web production, I picked up a > > copy of Macromedia Flash MX 2004, and made several small games and > > animations with that. I even created a small website to show off some of > my > > work, originally programmed in basic HTML with simple Javascript, and > then > > I > > moved to Dreamweaver. In an attempt to break out of two space graphics, I > > found Blender. Initially overwhelmed by all of the buttons, knobs, > sliders, > > menus, modes, and hotkeys, I eventually started creating several still > > pictures. I then moved on to basic animations and character animations, > and > > a few very simple games. When I found the video sequencer, I used it to > > slap > > together several films.vii <#127984db651a29d1_sdendnote7sym> > > > > I started getting very serious with programming when I went to > university. > > There, the main classes that they have taught in was Java. As such, that > is > > the language the majority of my code has been in. Currently, my most > > ambitious, although certainly not my most well written, completed project > > was a file compressor, which turned out to do very little compression > > whatsoever.viii <#127984db651a29d1_sdendnote8sym> I have a large chunk of > > my > > code available for checkout on my > > website.ix<#127984db651a29d1_sdendnote9sym>However, just because the > > majority of my code is in Java, that does not mean > > I don't know, and use other languages. Mainly to stretch my legs with C, > > but > > also as something to do in my time, I've started working on a simple pong > > game.x <#127984db651a29d1_sdendnote10sym> > > > > I've started contributing to Blender by creating an OFF exporter, which > was > > in Blender 2.4x, but not 2.5x.xi <#127984db651a29d1_sdendnote11sym> I'm > > currently working on an importer to go with it, and hope to have it done > > within the next few days. Once done with that, I will further get to know > > more about the actual core of Blender, by playing with it's window > manager, > > and fixing some simple bugs. Also, I am currently looking into the folder > > blender/source/tools, to see, as reported on the file system page, if it > is > > really being used at all.i Currently, Scons will compile without it, > > however, as it is a tools directory, it may be used for something besides > > just tools to change the code for various platforms, which is what it > > appears to be. > > > > All in all, I know Java, C, Python, Matlab, and to a lesser extent C++, > > Objective-C, Basic, Lisp, HTML, and a bit of PHP and Javascript. > > > > i <#127984db651a29d1_sdendnote1anc> > > > > > http://wiki.blender.org/index.php/Dev:2.5/Doc/Blender_Source/Files_structure > > > > ii <#127984db651a29d1_sdendnote2anc> > > http://www.cmake.org/Wiki/CMake_Testing_With_CTest > > > > iii <#127984db651a29d1_sdendnote3anc>http://www.cmake.org/ > > > > iv <#127984db651a29d1_sdendnote4anc> > > http://www.youtube.com/watch?v=vmhU_whC6zw&feature=channel > > > > v <#127984db651a29d1_sdendnote5anc> > > > http://www.amazon.com/Learn-Program-Basic-Windows-Macintosh/dp/B000N3W2L4 > > > > vi <#127984db651a29d1_sdendnote6anc>http://gamemaker.nl/ > > > > vii <#127984db651a29d1_sdendnote7anc>Http://leifandersen.blip.tv > > > > viii <#127984db651a29d1_sdendnote8anc> > > http://sourceforge.net/projects/lcompress/ > > > > ix <#127984db651a29d1_sdendnote9anc>svn://leifandersen.net > > > > x <#127984db651a29d1_sdendnote10anc> > > http://sourceforge.net/projects/pongrpg/ > > > > xi <#127984db651a29d1_sdendnote11anc> > > > > > https://projects.blender.org/tracker/index.php?func=detail&aid=21717&group_id=153&atid=467 > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers