RE: Cmocka adaptions for Behavior driven development
- Subject: RE: Cmocka adaptions for Behavior driven development
- From: "Vestre, Frederik" <Frederik.Vestre@xxxxxxxxxxxxx>
- Date: Thu, 29 Jun 2017 07:14:57 +0000
- To: Andreas Schneider <asn@xxxxxxxxxxxxxx>
- Cc: "cmocka@xxxxxxxxxxxxxx" <cmocka@xxxxxxxxxxxxxx>
> On Tuesday, 13 June 2017 13:57:20 CEST Vestre, Frederik wrote:
> > Hi
> Hello Frederick,
> > I have made some additions to cmocka to support BDD style testing (
> > loosely inspired by
> > https://github.com/philsquared/Catch/blob/master/docs/tutorial.md ).
> > Is it possible to get these changes included into cmocka, if so how do I proceed?
> this sounds like:
> is that the same?
It covers some parts of it, what it does not cover is the optional sections, i.e. to rerun the test
in all combinations skipping parts of it.
> > I have gotten permission from my manager to release this under the
> > Apache license in order to be compatible with the cmocka project. The
> > changes are attached to this e-mail. I also have the changes in a
> > local Git repository and can provide them in another format if that is preferable.
> I'm open for additions but I would like to keep the main library small. So it would be great to have this in an additional header (maybe even a > library).
I see, I will try to think of an architecture that splits out most of the logic, however I need to think a bit to find the best way to run the test functions multiple times without making the unittest code ugly. Maybe some hooks in the cmocka library are needed.
> The documentation should be added to doxygen so that everything is in one place.
I see, I will look into that.
> I would prefer to have git formatted patches. The smaller the commits the easier it is to review and integrate patches. Patches are also > easier to review an change.
Ok, I will keep sending that then (they are attached in the tarball to the previous e-mail).
> I'm not sure if cmocka forks is a good name, because of the confusion with the
> fork() system call :-)
I agree, I will think more if I find a better name for the concept of splitting execution into different branches.
> Does that make sense?
It does, I hope to have some updates at the end of the summer taking these things into account.