dune does the builds (so takes care of build dependencies) but opam does the packaging. opam in conjunction with tuareg does indeed ensure that the editor knows about new deps, but it’s true you need to go through opam to install them. I usually have a terminal open with dune build -w running, so it will rebuild on any changes, and ensure dependencies are kept up to date (e.g., if I add a new module or component somewhere in the project).
For testing, I am fond of qcheck for property based testing and alcotest for the test runner and unit tests. But OUnit is widely used, so I’m sure this is a good choice 
re: test automation, I have used circleCI for automating CI without much fuss. You can see my approach here. You may also be interested in the new GitHub actions announced in GitHub Actions for OCaml / opam now available
I think better opam/dune integration (or a wrapper tool to manage their interaction) will be coming before long, and it will make it much easier to manage dependencies. In the meantime, I have taken to including a Makefile with a rule like this:
.PHONY: deps
deps: $(opam_file)
# Update the package dependencies when new deps are added to dune-project
$(opam_file): dune-project
-dune build @install # Update the $(opam_file)
-git add $(opam_file) # opam uses the state of master for it updates
-git commit $(opam_file) -m "Updating package dependencies"
opam install . --deps-only # Install the new dependencies
Then make deps will update the opam package file and install new deps as needed. This depends on dune generation of opam files.