How to install/deploy Unity?

[nowox]

I quickly wrote an example to test Unity. I looked at the documentation on how to deploy it into my project, but I haven't found any useful information yet. So I'd like to ask it here.

What I did is write test/test_foo.c and hard copied unity.[ch] into my project repository in test/unity/. Then I realized I need to generate the testRunner. So I copied the auto ruby files into test/unity/auto/.

Now I can write a Makefile that call test/unity/auto/generate... script. Unfortunately all of this require to copy unity on every repository of every project. Another method is to add a submodule to Unity, but I don't think it worth it.

So the question is: where on the documentation is there a tutorial on how to quickstart a project with Unity? I initially though of installing something like gem install unity, but no, it isn't really the solution.

Any advice?

[mvandervoord]

Yves Hi. You are correct that there isn't a fast way to install just Unity. When people want to use Unity, typically they are looking for something minimal which they can put into their workflow themselves (in which case they grab Unity itself) or they are looking for most of the work to be done for them (in which case they tend to install Ceedling). If you install ceedling (gem install ceedling), you can create projects with "gem new projectname --as_gem". The as_gem part means that the ONLY additional requirement added to your local project is a ceedling project file. I think you might be happier with this setup... plus if you ever wanted to expand into using CMock, it'd already be set up for you. One final note: we're going to be improving the process of making a project into a ceedling project (right now your only option is to create a new one from scratch), but until then, you are probably going to want to just create a ceedling project in a blank directory and then copy the project file into the projects you want to use it in and just edit the paths and whatnot manually. Anyway, I'll stop rambling about this. If you have other questions as your work through things, just ask. Mark

…

On Thu, Oct 5, 2017 at 1:30 PM Yves Chevallier ***@***.***> wrote: I quickly wrote an example to test Unity. I looked at the documentation on how to deploy it into my project, but I haven't found any useful information yet. So I'd like to ask it here. What I did is write test/test_foo.c and hard copied unity.[ch] into my project repository in test/unity/. Then I realized I need to generate the testRunner. So I copied the auto ruby files into test/unity/auto/. Now I can write a Makefile that call test/unity/auto/generate... script. Unfortunately all of this require to copy unity on every repository of every project. Another method is to add a submodule to Unity, but I don't think it worth it. So the question is: where on the documentation is there a tutorial on how to quickstart a project with Unity? I initially though of installing something like gem install unity, but no, it isn't really the solution. Any advice? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#302>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABAf7LxAovFa4x-nyMajr1G6qpc3_s5ks5spRIggaJpZM4PvbuS> .

[cdcme]

Realize this is old, but fwiw, this threw me, too. IMO, for learning testing in C, the Ceedling+Unity+Cmock+CException route is perfect, but if you want to work in a CMake project (like those generated by CLion, for example), you're better off learning the concepts with Unity and using Criterion (more features/power) or Greatest(https://github.com/silentbicycle/greatest) (more minimal) in your real project—either of which is way easier to integrate into a production project. Nothing against Unity, it's awesome, but personally, I'm not going to spend time to install and configure a bunch of Ruby-based tools, etc., when I can more or less just drop a single file in my project, update CMakeLists, and get down to writing some tests.

[mvandervoord]

Thanks for the feedback, @carlodicelico.

Can I ask what makes Greatest easier than just dropping the 3 core Unity files into your project? In both cases, you are left hand-writing your own runner and managing your builds however you are going to manage them, aren't you? Does Greatest have something going that makes it simpler to use in this regard?

I'm definitely up for making this easier to use! :)

[cdcme]

Well, I was remarking more about the ruby tools mentioned, based on the OP's comment above about having to copy the auto ruby files, etc. Greatest and some of the others are admittedly not as feature-packed as the Ceedling approach, but simpler to integrate "the C way" IMO, compared to the Ceedling stuff, and doesn't require future C devs on the team to learn a new (and perhaps somewhat idiosyncratic in the ecosystem) ruby toolchain—they just use the same CMake workflow they likely are already familiar with.

With greatest, it's just one header file, so 2 files fewer than Unity 🤓. Somewhat less pedantically, though, it does provide a minimal runner in that single file, but can also just be used directly, without one, like any other C lib.

This took me maybe 15–20 minutes to figure out, implement, and write a first test, so pretty easy! I did not try adding Unity and writing my own runner, though, so possibly not an apples to apples comparison. In any case, one file to get assertions and basic runner I can expand on my own just seemed much easier.

[cdcme]

FWIW, this works with modern CMake (3.12, the most recent supported by CLion 2018.3):

In test/CMakeLists.txt:

# Sets up testing dependencies and adds project tests
macro(add_project_tests TESTNAME)
    # greatest unit testing lib
    set(GREATEST_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/extern/greatest)
    add_library(greatest INTERFACE)
    target_include_directories(greatest INTERFACE
            $<BUILD_INTERFACE:${GREATEST_INCLUDE_DIR}>
    )

    # theft property-based testing lib
    set(THEFT_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/extern/theft/inc)
    add_library(theft INTERFACE)
    target_include_directories(theft INTERFACE
            $<BUILD_INTERFACE:${THEFT_INCLUDE_DIR}>
    )

    add_executable(${TESTNAME} ${ARGN})
    target_link_libraries(${TESTNAME} greatest theft project_alias)
    add_test(${TESTNAME} ${TESTNAME})
    set_target_properties(${TESTNAME} PROPERTIES FOLDER test)
endmacro()

add_project_tests(test_runner runner.c)

And in your project root CMakeLists.txt, just set up your project_alias like add_library(lib_alias ALIAS yourlib), and enable testing (enable_testing) and add the test subdirectory (add_subdirectory(test)) as usual. In this case, I'm linking against the headers that are submodules in project_root/extern, and runner.c is my test runner. Then, in your CLion Run/Debug Configurations, you can just add your test_runner target and executable.

In this setup, Unity is no harder to set up than greatest, really. I think this or some variation of it would also work perfectly for Unity, as well, and might be worth a small section in the README or wiki?

[dontlaugh]

I'd like to globally install Unity as a library and use it from many C projects on a single system. This is what I've done (not sure if it's appropriate).

Building Unity

git clone git@github.com:ThrowTheSwitch/Unity.git
cd Unity
cmake .  # generates a Makefile
make     # build it
sudo make install  # install source and headers to /usr/local/src
sudo cp libunity.a /usr/local/lib  # put static archive on library path

Structure for a single C library project that uses Unity

/somelib
  Makefile
  lib.c
  lib.h
  lib.o  # built from Makefile
  /tests
    Makefile  # builds tests, runs tests
    test_lib.c
    test_config.h
    /bin
      ..test binaries built here..

The test_config.h file has the following

#ifndef __TEST_CONFIG_H
#define __TEST_CONFIG_H
/* must include before unity.h */
#define UNITY_INCLUDE_SETUP_STUBS
#define UNITY_WEAK_ATTRIBUTE
#endif

And lib_test.c looks like this, to use unity and test my own library functions

#include "test_config.h"
#include "unity.h"
#include "lib.h" /* my library */

void test_lib_func() { /* use my library and Unity stuff */ }

int main() {
    UNITY_BEGIN();
    RUN_TEST(test_lib_func);
    UNITY_END();
}

My tests/Makefile yields an invocation of gcc like the following

gcc -I.. -I/usr/local/src "test_lib".c ../*.o -L.. -lunity  -o bin/test_lib

The reason I'd like to install globally is to keep up with patches to Unity itself. I can just clone Unity and keep building and installing it from source.