drishti_add_test() features

[headupinclouds]

As expected, there are a few follow up issues and features related to drishti_add_test() that will be useful for day-to-day use, as this was merged for initial use before being feature complete (if that ever happens).

ios-deploy: It is difficult to kill ios-deploy calls, which I believe is due to reliance on lldb for launching apps. There is some discussion about this online.

PARALLEL: The testing mechanism should be updated for parallel use. Assuming 'adb' and 'ios-deploy' can run concurrently (TODO: confirm in docs/implementation) we can use a toolchain specific installation path on the test device (in the case of Android) or a unique BUNDLE_ID in the case of iOS in order to avoid conflicts. This is essentially the same as what would happen in HOST builds. This should provide protection for parallel builds+testing assuming each build has a unique toolchain. If the same toolchain is used in multiple builds we could still have a problem. This is an unlikely scenario, but it should at least be documented in the drishti_add_test interface. To cover all cases we could consider adding file(LOCK ...) inside CMake, where the lock would be created in a shared path between different toolchain builds (${HUNTER_ROOT}, ${CMAKE_SOURCE_DIR}/_locks, etc.)

The toolchain addition currently looks like this for iOS and ANDROID.

if(ANDROID)
    # ...
    if(CMAKE_TOOLCHAIN_FILE)
      get_filename_component(TOOLCHAIN_NAME ${CMAKE_TOOLCHAIN_FILE} NAME_WE)
      set(TESTING_DIR "${DRISHTI_ANDROID_DEVICE_TESTING_ROOT}/${PROJECT_NAME}/${TOOLCHAIN_NAME}")
    else()
      set(TESTING_DIR "${DRISHTI_ANDROID_DEVICE_TESTING_ROOT}/${PROJECT_NAME}")
    endif()
    # ...
elseif(IOS)
    # ...
    if(CMAKE_TOOLCHAIN_FILE)
      get_filename_component(TOOLCHAIN_NAME ${CMAKE_TOOLCHAIN_FILE} NAME_WE)
      set(BUNDLE_ID "${DRISHTI_IOS_BUNDLE_IDENTIFIER}.${TOOLCHAIN_NAME}.${APP_TARGET}")
    else()
      set(BUNDLE_ID "${DRISHTI_IOS_BUNDLE_IDENTIFIER}.${APP_TARGET}")
    endif()
   # ...
endif()

A CLEAN and DOWNLOAD policy of some sort should be added.

For general build tests, having a mechanism to start from a clean slate is desirable:

• for android we can rm -rf /data/local/tmp/drishtisdk before starting all tests
• (optional) rm -rf /data/local/tmp/drishtisdk after running, however, having an option for some persistent output could be desirable -- example: we may want to debug an image processing algorithm with some annotated image, or compare the results between an iOS and an Android run... such a feature could be accomplished with something like a DOWNLOAD device_folder host_folder feature.

Note: I've noticed that the ios-deploy device tests seem to end up installing each test-drishti-<module> application twice.

[ruslo]

for android we can rm -rf /data/local/tmp/drishtisdk before starting all tests
rm -rf /data/local/tmp/drishtisdk after running

Implementation notes: cleanup fixture before all tests started and after tests finished.

I've noticed that the ios-deploy device tests seem to end up installing each test-drishti- application twice

Install will be run for each drishti_add_test directive even if we are running same application, e.g.:

add_executable(foo ...)
drishti_add_test(NAME FooTest1 COMMAND foo --arg1)
drishti_add_test(NAME FooTest2 COMMAND foo --arg2)

will install foo twice: one for FooTest1 and another for FooTest2. This can be fixed by using install fixture.

[headupinclouds]

Project migrated to https://github.com/hunter-packages/gauze