User Tools

Site Tools


unit_test_case_utc

Introduction

IoTivity Constrained is a memory and process agnostic implementation of OCF spec, to enable IoTivity stack to run on light weight devices with little memory and processing power. Currently, there are test cases for Linux platform.

General Information

Unit test cases are developed alongside IoTivity Constrained APIs, are built with library build, and are run in Jenkins verification to verify each commit.

Configuration

This includes setting up development environment for various platforms and cloning IoTivity source from Gerrit.

Linux Platform:

Firstly, open a terminal and follow below process.

  1. Install Build-essential
    $ apt-get install build-essential
  2. Install GNU make
    $ sudo apt-get install make
  3. Install Libtool
    $ apt-get install libtool
  4. Install Gettext
    $ apt-get install gettext
  5. Install expat
    $ apt-get install libexpat1-dev
  6. Install Libssl-dev
    $ apt-get install libssl-dev
  7. Install libcurl4-openssl-dev
    $ apt-get  install libcurl4-openssl-dev
  8. Install UUID Library
    $ apt-get install uuid-dev 
  9. Install Git
    $ apt-get install git-core
  10. Install ssh
    $ apt-get install ssh
  11. Install Libglib
    $ apt-get install libglib2.0-dev

Cloning Iotivity Source

  1. Create ssh keys [skip this step, if you want to use existing ssh keys]
    1. On the terminal, type the following (replace “your name <your_email_address>” with your name and email address)
      $ ssh-keygen -t rsa -C "your name"
    2. After pressing the Enter key at several [LS6] prompts, an ssh key-pair will be created at ~/.ssh/id_rsa.pub.
      $ ssh-keygen -t rsa -C "John Doe john.doe@example.com"
  2. Upload and register an ssh public key
    1. Log in to IoTivity Gerrit
    2. Click on Settings on the top right side as shown here
    3. Click on SSH Public Keys and add key
    4. Open ~/.ssh/id_rsa.pub, copy the content, and paste the content in the “Add SSH Public Key” window
    5. Click Add
  3. Setting up ssh
    1. Open ~/.ssh/config in a text editor
    2. Add the following line
      • Host iotivity gerrit.iotivity.org
      • Hostname gerrit.iotivity.org
      • IdentityFile ~/.ssh/id_rsa
      • User [Insert_your_username_here]
      • Port 29418
    3. To connect behind the proxy, add the following line after IdentityFile ~/.ssh/id_rsa with the appropriate proxy address and port
      1. ProxyCommand nc -X5 -x <proxy-address>:<port> %h %p
  4. Verify your ssh connection
    1. Execute the following command in the terminal window
      $ ssh gerrit.iotivity.org
    2. Upon successful connection, the following message should appear indicating proper ssh and configuration connection:
      ******Welcome to Gerrit Code Review****** 
    3. If the connection is not established, check for the proxy and use the proxy settings described in Step c of 3
  5. Cloning the project source
    1. Using your terminal window, browse to the directory where code will be checked out.
    2. Execute the following command in the terminal window to clone the IoTivity Constrained repository:
      $ git clone --recursive ssh://gerrit.iotivity.org:29418/iotivity-constrained && scp -p -P 29418 gerrit.iotivity.org:hooks/commit-msg iotivity-constrained/.git/hooks/
      • This command clones the repository in your current working directory.

Build

  1. Linux Source Build
    • To build IoTivity for Linux, go to Linux port folder and run make in a terminal
      $ cd iotovoty-constrained/port/linux
      $ make all
    • Extra build commands can be supplied as required, e.g.
      $ make all DEBUG=1 SECURED=1 DYNAMIC=1

UTC Build

  • To build UTC, execute:
    $ make test

Run

  1. UTCs are automatically run after successful build.
  2. To run again, please execute:
    $./apitest

Develop UTC

This section describes some basic ground rules for Unit TC.

Generic Guideline:

  1. Testcase files should reside in same level of folder structure of the API containing file.
  2. All testcases should be independent(able to run single and should not affect next/other testcases)
  3. Unit TCs should be written to verify API signature and response in basic case, not API behavior in a specific scenario.
  4. All precondition required for a TCs should reside in SetUp() function
  5. To make each Testcase independent, required cleanups should be done inside TearDown()
  6. If a TC is desired to use the defined SetUp() & TearDown() functions, it should start with “TEST_F”, otherwise, “TEST” should be used.
unit_test_case_utc.txt · Last modified: 2018/05/08 08:28 by Mushfiqul Islam