Page MenuHomePhabricator

[services] Tests - Fix scripts
ClosedPublic

Authored by karol on Jun 6 2022, 4:41 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 10, 4:42 AM
Unknown Object (File)
Sun, Nov 10, 2:15 AM
Unknown Object (File)
Sun, Nov 10, 2:11 AM
Unknown Object (File)
Sun, Nov 10, 2:04 AM
Unknown Object (File)
Sun, Nov 10, 2:00 AM
Unknown Object (File)
Sun, Nov 10, 1:29 AM
Unknown Object (File)
Sun, Nov 10, 12:15 AM
Unknown Object (File)
Sun, Nov 10, 12:10 AM

Details

Summary

Depends on D4250

I changed my approach a bit when it comes to testing the services.

I divided the tests into two groups:

  • unit tests
  • integration tests

Now, if you want to run the tests for one service/all services, you'll do something like this:

yarn run-unit-tests backup
yarn run-integration-tests backup
yarn run-unit-tests blob
yarn run-integration-tests blob
yarn run-unit-tests all
yarn run-integration-tests all
Test Plan
cd services
yarn run-unit-tests
yarn run-integration-tests

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
karol retitled this revision from [services] Tests - Add scripts to [services] Tests - Fix scripts.Jun 13 2022, 6:52 AM
karol edited the test plan for this revision. (Show Details)

Didn't we agree that once the nix is fully integrated we can replace npm with it here?

Does Nix really replace npm in this way? I would guess that in Nix, we would still need something like a bash script. Nix would just let us add the bash script to $PATH or something, but it doesn't have an equivalent of package.json's scripts section (I think)

tomek requested changes to this revision.Jun 14 2022, 2:47 AM
tomek added inline comments.
services/scripts/run_integration_tests.sh
12 ↗(On Diff #13472)
12 ↗(On Diff #13472)

Why do we need to use $1 in two places? (env variable and $1_test expression?

41 ↗(On Diff #13472)

Should we somehow set a return value of the script so that when a test fails, the caller of this script would know it? Also, when we run a couple of tests and any of them fails, we should return a non-zero code. (It depends on our CI if that is really needed, but we need to somehow let CI know that a test failed).

services/scripts/run_unit_tests.sh
35–37 ↗(On Diff #13472)

We assume here that one service name can't be a substring of other service name. Is there a way to avoid this assumption?

This revision now requires changes to proceed.Jun 14 2022, 2:47 AM

Didn't we agree that once the nix is fully integrated we can replace npm with it here?

Does Nix really replace npm in this way? I would guess that in Nix, we would still need something like a bash script. Nix would just let us add the bash script to $PATH or something, but it doesn't have an equivalent of package.json's scripts section (I think)

All in all, we can get back to this once the nix stuff is done, right? https://linear.app/comm/issue/ENG-1259/get-rid-of-npm-for-calling-services-scripts

services/scripts/run_integration_tests.sh
12 ↗(On Diff #13472)

This is because we first need to pass the env var to the build script which then compiles the proper proto file. Then we need to launch the target test. I'm not sure what's wrong with using $1 twice?

41 ↗(On Diff #13472)

We have set -e for that.

services/scripts/run_unit_tests.sh
35–37 ↗(On Diff #13472)

We probably can do it differently but I'm not sure if we need it. I'd say this is a low-prio stuff, I created a task for this: https://linear.app/comm/issue/ENG-1258/enable-one-service-name-to-be-a-substring-of-another-one

tomek added inline comments.
services/scripts/run_integration_tests.sh
12 ↗(On Diff #13472)

It feels like a duplication and increases the possibility of a mistake. If we compile the code with env variable set, is it possible to run the result for a different service, e.g. can COMM_TEST_TARGET=backup cargo test blob_test --test '*' --manifest-path=commtest/Cargo.toml run correctly? My point is, if these two always need to have the same value, there's no point in separating them. What do you think?

41 ↗(On Diff #13472)

Ok, that makes sense. But are we sure that run_integration_test $SERVICE returns non-zero in case of a single test failure?

This revision is now accepted and ready to land.Jun 14 2022, 5:17 AM
In D4216#120035, @karol-bisztyga wrote:

Didn't we agree that once the nix is fully integrated we can replace npm with it here?

Does Nix really replace npm in this way? I would guess that in Nix, we would still need something like a bash script. Nix would just let us add the bash script to $PATH or something, but it doesn't have an equivalent of package.json's scripts section (I think)

All in all, we can get back to this once the nix stuff is done, right? https://linear.app/comm/issue/ENG-1259/get-rid-of-npm-for-calling-services-scripts

Sounds good, thanks for creating a task 👍

services/scripts/run_integration_tests.sh
26 ↗(On Diff #13479)

bug

12 ↗(On Diff #13472)

With the changes added to D4161 we no longer need COMM_TEST_TARGET so this is solved, I will push according changes here.

41 ↗(On Diff #13472)

yes

I explicitly re-checked and if one test fails, the whole script does as well.

jon added inline comments.
services/scripts/run_integration_tests.sh
8 ↗(On Diff #14017)

probably want to canonicalize the path before invoking, or else invoking this from the project root will cause this to resolve incorrectly

9 ↗(On Diff #14017)

may want to assert that someone invoked the script with an argument

I think @yayabosh should review any bash going forward, he's done some really good reviews on it

services/scripts/run_unit_tests.sh
1 ↗(On Diff #14076)

@yayabosh can you run your Bash sanitizer here and see how it looks?

22 ↗(On Diff #14076)

Please don't introduce any more single-bracket conditionals in bash, @yayabosh is working in ENG-157 to fix this...

This revision now requires review to proceed.Jul 2 2022, 6:32 PM

@ashoat I can also add shellcheck to the nix dev env. Closest thing to a linter for bash, that I'm aware of.

karol added inline comments.
services/scripts/run_integration_tests.sh
8 ↗(On Diff #14017)

Why would anyone want to trigger this from the root directory? If this is needed, we can always use cd/pushd.

We do not do this in any script, I think we should either apply this technique in all scripts as a follow-up or nowhere.

I do not mind personally, but I don't think this will be super useful. What's your opinion?

9 ↗(On Diff #14017)

this is done here:

if [ -z "$1" ]; then
  echo "No service specified";
  list_expected;
  exit 1;
fi

I can add all option to the hint.

@yayabosh when can I expect a review from you here? You are a blocking reviewer... thx

Some style fixes here and there! Should be good after that.

services/scripts/list_services.sh
5

Don't use ls | grep. Use a glob or a for loop with a condition to allow non-alphanumeric filenames.

This suggested edit looks kind of messy and that's because find (both the GNU and BSD variants) do not support lookahead/lookbehind. So it's just a suggested solution, but you can also use a for loop or if statement to loop through the files.

services/scripts/run_integration_tests.sh
8
13
30
35

Not that it really matters in this particular instance since the command ends right after the variable is set, but you can use a here string instead of the echo + pipe. In my opinion it looks cleaner and if the script did go further, you could run into some issues using echo.

Also make sure to double quote to prevent globbing and word splitting and use $(...) notation instead of legacy backticked ...

43
services/scripts/run_unit_tests.sh
8
13
14
30
35

Not that it really matters in this particular instance since the command ends right after the variable is set, but you can use a here string instead of the echo + pipe. In my opinion it looks cleaner and if the script did go further, you could run into some issues using echo.

Also make sure to double quote to prevent globbing and word splitting and use $(...) notation instead of legacy backticked ...

43
This revision now requires changes to proceed.Jul 5 2022, 8:45 AM

Looks good! Accepting, assuming the Test Plan has been re-run on the latest version of this diff.

This revision is now accepted and ready to land.Jul 6 2022, 9:30 AM
This revision was landed with ongoing or failed builds.Jul 8 2022, 2:30 AM
This revision was automatically updated to reflect the committed changes.