From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 85347A052A; Wed, 27 Jan 2021 19:28:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42D2814103F; Wed, 27 Jan 2021 19:28:58 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id B0662141035 for ; Wed, 27 Jan 2021 19:28:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611772136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H2ojdouYAxT4A0JkZ9D/1xVD2XZfrdzh13tjXiOvMTk=; b=ZgFP5zRM6g+pIwCkf3d13Fjqkl48rYlRT1f7bD3fQfTCi/BfQgIDtc46eEgBn61RVY1ys7 7HQ+EKzTtMNZo1Dx8scK8+krK8wnaaq06uaHfnLSITUEZjnbT7RO7HvewU2NmLDvxSyztk Sjh/8qx4B49u86tHhvaTPwjGzc5YfoQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-469-tVxoquR-PROnKVZFH6QoMw-1; Wed, 27 Jan 2021 13:28:55 -0500 X-MC-Unique: tVxoquR-PROnKVZFH6QoMw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8E16107ACE6; Wed, 27 Jan 2021 18:28:53 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-114-243.rdu2.redhat.com [10.10.114.243]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0D1DA5D9C6; Wed, 27 Jan 2021 18:28:52 +0000 (UTC) From: Aaron Conole To: Bruce Richardson Cc: dev@dpdk.org, Ray Kinsella References: <20210127151618.632975-1-aconole@redhat.com> <20210127172909.GA847@bricha3-MOBL.ger.corp.intel.com> Date: Wed, 27 Jan 2021 13:28:50 -0500 In-Reply-To: <20210127172909.GA847@bricha3-MOBL.ger.corp.intel.com> (Bruce Richardson's message of "Wed, 27 Jan 2021 17:29:09 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=aconole@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [dpdk-dev] [RFC] doc: add a guide to describe developing tests X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Bruce, Thanks for the review! Responses below. Bruce Richardson writes: > On Wed, Jan 27, 2021 at 10:16:18AM -0500, Aaron Conole wrote: >> The DPDK testing infrastructure includes a comprehensive set of >> libraries, utilities, and CI integrations for developers to test >> their code changes. This isn't well documented, however. >> >> Document the basics for adding a test suite to the infrastructure >> and enabling that test suite for continuous integration platforms >> so that newer developers can understand how to develop test suites >> and test cases. >> >> Signed-off-by: Aaron Conole > > Thanks for starting this Aaron, this doc is well needed. Couple of comments > below. > > /Bruce >> --- >> Submitting as RFC as I'm not sure if this should include making >> changes to the github actions or travis yml, or the linux-build >> ci script. >> >> doc/guides/contributing/index.rst | 1 + >> doc/guides/contributing/testing.rst | 200 ++++++++++++++++++++++++++++ >> 2 files changed, 201 insertions(+) >> create mode 100644 doc/guides/contributing/testing.rst >> > >> +The second form is useful for a scripting environment, and is used by >> +the DPDK meson build system. This mode is invoked by assigning a >> +specific test suite name to the environment variable `DPDK_TEST` >> +before invoking the `dpdk-test` command, such as:: >> + >> + $ DPDK_TEST=version_autotest ./build/app/test/dpdk-test --no-huge >> + EAL: Detected 4 lcore(s) >> + EAL: Detected 1 NUMA nodes >> + EAL: Static memory layout is selected, amount of reserved memory >> can be adjusted with -m or --socket-mem >> + EAL: Multi-process socket /run/user/26934/dpdk/rte/mp_socket >> + EAL: Selected IOVA mode 'VA' >> + EAL: Probing VFIO support... >> + EAL: PCI device 0000:00:1f.6 on NUMA socket -1 >> + EAL: Invalid NUMA socket, default to 0 >> + EAL: probe driver: 8086:15d7 net_e1000_em >> + APP: HPET is not enabled, using TSC as default timer >> + RTE>>version_autotest >> + Version string: 'DPDK 20.02.0-rc0' >> + Test OK >> + RTE>>$ >> + >> +The above shows running a specific test case. On success, the return >> +code will be '0', otherwise it will be set to some error value (such >> +as '255'). >> + > > This reminds me that I have patch almost ready to submit to extend this > support to allow passing the test name - or even multiple test names - on > the commandline, not just through the environment. Will upstream it > shortly, I hope. I think command-line is more usable for folks than the > environment. Thoughts? I agree, such a change would be really useful as a developer. I have no preference when it comes to the scripting side though (which is what this section is about). Either we set env in the script, or we pass as command line. >> + > >> + >> +Designing a test >> +---------------- >> + >> +Test cases have multiple ways of indicating an error has occurred, >> +in order to reflect failure state back to the runner. Using the >> +various methods of indicating errors can assist in not only validating >> +the requisite functionality is working, but also to help debug when >> +a change in environment or code has caused things to go wrong. >> + >> +The first way to indicate a generic error is by returning a test >> +result failure, using the *TEST_FAILED* error code. This is the most >> +basic way of indicating that an error has occurred in a test routine. >> +It isn't very informative to the user, so it should really be used in >> +cases where the test has catastrophically failed. >> + >> +The preferred method of indicating an error is via the >> +`RTE_TEST_ASSERT` family of macros, which will immediately return >> +*TEST_FAILED* error condition, but will also log details about the >> +failure. The basic form is: >> + >> +.. code-block:: c >> + >> + RTE_TEST_ASSERT(cond, msg, ...) >> + >> +In the above macro, *cond* is the condition to evaluate to **true**. >> +Any generic condition can go here. The *msg* parameter will be a >> +message to display if *cond* evaluates to **false**. Some specialized >> +macros already exist. See `lib/librte_eal/include/rte_test.h` for >> +a list of pre-build test assertions. >> + > > Maybe also mention TEST_SKIPPED return value. Okay, I will add some description about it.