Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No tests were found #113

Closed
fletching opened this issue Jul 17, 2020 · 6 comments
Closed

No tests were found #113

fletching opened this issue Jul 17, 2020 · 6 comments
Labels

Comments

@fletching
Copy link

fletching commented Jul 17, 2020

Describe the bug
make test on a freshly cloned repository does not find any tests.

To Reproduce
Steps to reproduce the behavior:

  1. git clone https://github.com/nasa/cFS.git
  2. cd cFS
  3. cp cfe/cmake/Makefile.sample Makefile
  4. cp -r cfe/cmake/sample_defs sample_defs1
  5. make SIMULATION=native ENABLE_UNIT_TEST=true prep
  6. make
  7. make install
  8. make test

Observed behavior

lcov --capture --initial --directory build/native/default_cpu1 --output-file build/native/default_cpu1/coverage_base.info
Capturing coverage data from build/native/default_cpu1
Found gcov version: 9.3.0
Using intermediate gcov format
Scanning build/native/default_cpu1 for .gcno files ...
geninfo: WARNING: no .gcno files found in build/native/default_cpu1 - skipping!
Finished .info-file creation
(cd build/native/default_cpu1 && ctest -O ctest.log)
Test project /home/XXX/cFS/cFS-ic/build/native/default_cpu1
No tests were found!!!

Expected behavior
Tests run and pass.

System observed on:
VirtualBox 6.1 running Linux Mint 20, Kernel: Linux 5.4.0-40-generic, Architecture: x86-64

@jphickey
Copy link
Contributor

Note - something like this could be caused by submodules being out of sync. Can you confirm if you did a "git submodule update' as part of this?

There was a recent change that affected the directory structure of the build tree, so if this was out of sync it would potentially manifest as not finding any test files.

@fletching
Copy link
Author

Yes, I forgot to include the git submodule init and git submodule update commands from my steps to reproduce. I did run git submodule update as part of my setup and got those results. I tried it both on master and integration-candidate and the same thing happened.

@jphickey
Copy link
Contributor

Did you do this before or after the "cp cfe/cmake/Makefile.sample Makefile" step?

The sample makefile might contain a line "ARCH ?= native" or "ARCH ?= native/default_cpu1" reflecting the recent change to the build tree.

Check your generated build tree and see if the actual build binaries are in the "native" subdir or a "native/default_cpu1" subdir.

@fletching
Copy link
Author

I updated the submodules prior to copying the Makefile, even after changing to the integration-candidate branch.

The sample Makefile I copied has ARCH ?= native on master and ARCH ?= native/default_cpu1 on integration-candidate. The directories for the binaries are correct for both branches.

@jphickey
Copy link
Contributor

Ah hah --- I see it -- ENABLE_UNIT_TEST=true should be ENABLE_UNIT_TESTS=true

@fletching
Copy link
Author

🤦 Yes! Thank you!!

PaulaBosca pushed a commit to McMasterNEUDOSE/cFS that referenced this issue Aug 17, 2020
Fixes nasa#112 
Code reviewed and approved at 20191106 CCB
chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
Using a union for the ack/nak counts is somewhat dangerous because
undefined behavior will occur if accessed improperly.  In this case
there is no need to have separate representations of the counter,
they are both limited to the "unit8" range, so use a uint8.
chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
The use of random numbers in a couple test cases was causing an
unpredictable flow through the code.  This replaces with fixed
values so get consistent flows.

Specifically, the "acknak_count" should always be less than the
"ack_limit".  The UT use of random numbers allowed it to be
greater.  However, if it is greater than the limit, it should
still follow the limit/error path, not the successful path.
chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants