-
Notifications
You must be signed in to change notification settings - Fork 82
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
[PM-13008] Add ldap integration tests #637
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #637 +/- ##
========================================
+ Coverage 2.29% 8.62% +6.33%
========================================
Files 59 60 +1
Lines 2573 2655 +82
Branches 467 475 +8
========================================
+ Hits 59 229 +170
+ Misses 2511 2403 -108
- Partials 3 23 +20 ☔ View full report in Codecov by Sentry. |
New Issues
|
Testing based on last modified date is probably too difficult to scale once we start using cloud directory services
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether this should be separate to the existing test.yml
file. As we add more integration tests it seems useful to keep it separate, but I'm not sure how this affects code coverage reporting.
As it stands this is mostly a copy/paste of test.yml
.
We may want to use https://github.com/dorny/paths-filter down the line to selectively run different tests based on which directory service was changed. (The standard path filter only applies to the whole workflow, not steps within it.)
src/models/groupEntry.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The toJSON
/fromJSON
methods were added as helpers to instantiate the fixture data. It's maybe a bit weird to add this to runtime code, but the Jsonify
type is based on the toJSON
return type, so it was the tidiest and least verbose way to add type safety and factory methods to the fixture data.
beforeEach(() => { | ||
logService = mock(); | ||
i18nService = mock(); | ||
stateService = mock(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future refactor: it would be good to remove stateService
from the directory service implementations and pass in their config as arguments instead.
getLdapConfiguration({ | ||
ssl: true, | ||
startTls: true, | ||
sslAllowUnauthorized: true, // TODO: this could be more robust if we configured certs correctly | ||
}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of a half baked SSL config at the moment, I just wanted something in place. Ideally we'd specify a certificate and not use sslAllowUnauthorized
.
# Tests in apps/ are typechecked when their app is built, so we just do it here for libs/ | ||
# See https://bitwarden.atlassian.net/browse/EC-497 | ||
- name: Run typechecking | ||
run: npm run test:types --coverage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably don't need this, it's not required to run tests and is already done in the main test job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in bda1104.
@@ -0,0 +1 @@ | |||
COMPOSE_PROJECT_NAME=directory-connector |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make more sense to set this in docker-compose.yml
? Docker's documentation says it will take the top level name
value here.
Also, if you're planning to use this as the scaffolding location for local development containers it doesn't make sense to put it in the integration-tests
folder. I do think it's reasonable to put docker-compose.yml
(and .env
if you keep it) in project root.
I realised belatedly that the OpenLDAP Docker image is unmaintained since ~3 years ago: https://github.com/osixia/docker-openldap. I'll look at changing it out for https://hub.docker.com/r/bitnami/openldap, which appears maintained and published by Vmware. Other suggestions are welcome. |
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-13008
See the parent ticket https://bitwarden.atlassian.net/browse/PM-13007 for additional context.
📔 Objective
Add integration tests for
LdapDirectoryService
.We don't have any integration tests for our directory services, so this was a bit of trial and error, and is open to feedback about the best way to structure these.
The tests use jest because I still needed a test runner and I wanted to isolate
LdapDirectoryService
from the rest of the app and from the Bitwarden server. The integration is purely between our directory service implementation and the external directory service, which to me is the "here be dragons" part of our code at the moment.This PR uses the OpenLdap docker image that we already recommend for local development. That's ideal because we can spin it up with seed data on demand. Additional integration tests will probably involve actual third party cloud services or Azure VMs which will require more investigation and setup.
Once this is merged I can remove the OpenLdap configuration from the
server
repository and update the contributing docs. It really belongs with this repo.📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes