This meant that we owned both sides of the product implementation. For unit testing on the frontend, we stayed with Angular’s suggestion of Jasmine. For unit testing on the backend, we went with rspec-rails. These worked well since unit tests don’t need to cross technology boundaries.

Unit tests are usually cheap, and you should consider them like the basement of your house

The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible

Unit tests for operations: They test all edge cases in a nice, fast unit test environment without any HTTP involved.

Yes; everything needed to run the tests are bundled inside the test suite or executable. There's no connections to foreign processes or systems. I.e, no talking to databases or reading files from disk. If necessary, these connection points are faked / mocked.

I should also add that I'm in favor of relying more heavily on integration testing. When you do this, you need to unit test fewer of your simple components and wind up only having to unit test edge cases for components (which can mock all they want).

Unit test coverage grants confidence that code logic is correct(and serves as great developer documentation!)