[SSSD] [PATCH] TEST: recent_valid filter testing
Jakub Hrozek
jhrozek at redhat.com
Fri Nov 13 11:27:03 UTC 2015
On Fri, Nov 13, 2015 at 12:00:36PM +0100, Lukas Slebodnik wrote:
> On (13/11/15 11:32), Jakub Hrozek wrote:
> >On Fri, Nov 13, 2015 at 10:52:08AM +0100, Petr Cech wrote:
> >> On 11/13/2015 10:30 AM, Petr Cech wrote:
> >> >On 11/13/2015 10:27 AM, Petr Cech wrote:
> >> >>
> >> >>Patches are rebased now. I hope it will be ok now.
> >> >>
> >> >>Petr
> >> >Sorry, now my local CI tests failed... I will rebase it again.
> >>
> >> Well, now it is right. Local CI tests passed. There has been patch:
> >>
> >> "TESTS: Fix warnings -Wshadow":
> >> commit df9e9a1f9b7dc255eb62c390163c25917b08f5a2
> >> Refs: sssd-1_13_1-137-gdf9e9a1
> >> Author: Lukas Slebodnik <lslebodn at redhat.com>
> >> AuthorDate: Mon Nov 9 10:59:55 2015 +0100
> >> Commit: Jakub Hrozek <jhrozek at redhat.com>
> >> CommitDate: Tue Nov 10 15:34:41 2015 +0100
> >>
> >> There is change
> >> # - time_t time)
> >> # + time_t transaction_time)
> >> in static void prepare_user().
> >> My patches were in conflict with it.
> >>
> >> Regards
> >>
> >> Petr
> >
> >> From 3ce6073dda27fd7a4626f5cbac1c765274ca5fe0 Mon Sep 17 00:00:00 2001
> >> From: Petr Cech <pcech at redhat.com>
> >> Date: Fri, 2 Oct 2015 07:34:08 -0400
> >> Subject: [PATCH 1/8] TEST: Add test_user_by_recent_filter_valid
> >>
> >> Test users_by_filter_valid() was removed in past. We will add two new
> >> tests instead of it. Logic of those tests is connected to RECENT
> >> filter. It returns only records which have been wrote or updated after
> >> filter was created (or another given time).
> >>
> >> users_by_filter_valid() --> user_by_recent_filter_valid()
> >> users_by_recent_filter_valid()
> >>
> >> The first of new tests, user_by_recent_filter_valid(), counts with two
> >> users. One is stored before filter request creation and the second user
> >> is stored after filter request creation. So filter returns only one
> >> user.
> >>
> >> The second of new tests, users_by_recent_filter_valid(), counts with
> >> three users. One is stored before filter request creation and two users
> >> are stored after filter request creation. So filter returns two users.
> >>
> >> This patch adds user_by_recent_filter_valid().
> >>
> >> Resolves:
> >> https://fedorahosted.org/sssd/ticket/2730
> >> ---
> >> src/tests/cmocka/test_responder_cache_req.c | 50 +++++++++++++++++++++++++++++
> >> 1 file changed, 50 insertions(+)
> >>
> >> diff --git a/src/tests/cmocka/test_responder_cache_req.c b/src/tests/cmocka/test_responder_cache_req.c
> >> index 85d986bd7d159dc238bce4bc770272d18288f2dd..14a40ae6e56b2f6d0b18608bac09bc4680245153 100644
> >> --- a/src/tests/cmocka/test_responder_cache_req.c
> >> +++ b/src/tests/cmocka/test_responder_cache_req.c
> >> @@ -1239,6 +1239,53 @@ static void cache_req_user_by_filter_test_done(struct tevent_req *req)
> >> ctx->tctx->done = true;
> >> }
> >>
> >> +void test_user_by_recent_filter_valid(void **state)
> >> +{
> >> + struct cache_req_test_ctx *test_ctx = NULL;
> >> + TALLOC_CTX *req_mem_ctx = NULL;
> >> + struct tevent_req *req = NULL;
> >> + const char *ldbname = NULL;
> >> + errno_t ret;
> >> +
> >> + test_ctx = talloc_get_type_abort(*state, struct cache_req_test_ctx);
> >> + test_ctx->create_user = true;
> >> +
> >> + ret = sysdb_store_user(test_ctx->tctx->dom, TEST_USER_NAME2,
> >> + "pwd", 1001, 1001, NULL, NULL, NULL,
> >> + "cn="TEST_USER_NAME2",dc=test",
> >> + NULL, NULL, 1000, time(NULL)-1);
> >> + assert_int_equal(ret, EOK);
> >> +
> >> + req_mem_ctx = talloc_new(test_ctx->tctx);
> >> + check_leaks_push(req_mem_ctx);
> >
> >I think the last question is whether we want to use this new context or
> >just call check_leaks_push(test_ctx) recursively. I don't really mind
> >too much, both would work for me.
> >
> >Unless someone opposes, I would push the patch as-is.
> >
> I have a different question. (i haven't read patches yet)
> But I can see that check_leaks_push is called after sysdb_store_user.
>
> I would like to know why.
> because we shout try to check leaks "caused" in this function.
Wouldn't these leaks be caught by leaks checks that are pushed in
setup() and popped in teardown() ?
More information about the sssd-devel
mailing list