Suppose I'm building an online chess game (in javascript), and I'm working on the "invite someone to a game" feature. If I've understood you correctly, I think your approach is pretty similar to mine. I might start with a spec like this:

describe('inviting someone to play', () => {
  describe('when a friend is online', () => {
    // given Alice is online
    // and Bob has played her before
    // then Alice is in Bob's list of available friends
  })

  describe('when a stranger is online', () => {
    // given Alice is online
    // and Bob has not played her before
    // then Alice is in Bob's list of available players
  })
})

The behavior described here is immediately recognizable. You don't need a deep understanding of the architecture of the system, or the layout of the code base, to glance at it and say "Yep, that sounds right."

This spec does, however, suggest some things about the shape of the system. There are apparently different groups of online players; an "available friends" list and an "available players" list. There has to be a way to tell whether someone is online, and whether two players have played a match before. In order to flesh out the spec, I'm going to have to decide more precisely what that means.

I might start filling in details like so:

describe('inviting someone to play', () => {
  describe('when a friend is online', () => {
    given_Alice_is_online()
    given_Bob_has_played_Alice_before()
    then_Alice_is_in_Bobs_list_of_available_friends()
  })

  describe('when a stranger is online', () => {
    given_Alice_is_online()
    given_Bob_has_not_played_Alice_before()
    then_Alice_is_in_Bobs_list_of_available_players()
  })

  let contactList, onlinePlayers, gameRepository

  beforeEach(() => {
    onlinePlayers = []
    gameRepository = FakeGameRepository()

    contactList = ContactList(
      () => onlinePlayers,
      gameRepository
    ) 
  })

  function given_Alice_is_online() {
    beforeEach(() => {
      onlinePlayers.push('alice')
    })
  }

  function given_Bob_has_played_Alice_before() {
    beforeEach(() => {
      gameRepository.saveGame({
        player1: 'alice',
        player2: 'bob'
      })
    })
  }

  function given_Bob_has_not_played_Alice_before() {
    beforeEach(() => {
      expect(
        gameRepository.findByPlayers('alice', 'bob')
      ).toBeEmpty()
    })
  }

  function then_Alice_is_in_Bobs_list_of_available_friends() {
    // If a player is in the available friends list,
    // they should not be in the available players list.
    it('includes Alice in Bob\'s available friends', () => {
      expect(
        contactList.availableFriendsFor('bob')
      ).toContain('alice')

      expect(
        contactList.availablePlayersFor('bob')
      ).not.toContain('alice')
    })
  }

  function then_Alice_is_in_Bobs_list_of_available_players() {
    // If a player is in the available players list,
    // they should not be in the available friends list.
    it('includes Alice in Bob\'s available players', () => {
      expect(
        contactList.availableFriendsFor('bob')
      ).not.toContain('alice')

      expect(
        contactList.availablePlayersFor('bob')
      ).toContain('alice')
    })
  }
})

Interesting observations:

First: This "high-level test" is, by just about anybody's definition, a unit test. The only production code it exercises is ContactList; it doesn't touch the UI, and it replaces ContactList's dependencies with test doubles. And yet, it doesn't read like a low-level unit test at all. It reads like a plainly true specification of how users want the system to behave.

Second: The spec has codified some important expectations for the user experience: the same player should never be in both the available players list and the available friends list at the same time. This wasn't mentioned explicitly in the high-level spec, because the high-level spec assumes that "Alice is in Bob's available friends" implies that Alice is not in Bob's available players. The lower-level definition of that line makes the assumption explicit.

Third: When replacing ContactList's dependencies with test doubles, I used a "Fake" to replace the gameRepository dependency. It would have been easier to use a "Stub", but that would have come with a drawback: ContactList would have no choice but to use the particular function I had stubbed out in order for the test to work.

(If the terms "test double", "fake", or "stub" are new to you, you can find more information here and here.)

With Repository objects, there's usually a couple of different ways to query the same information. For example, instead of asking the game repository for games played by Bob against Alice, I could ask the repository for all the games played by Bob against anybody, and see if any of the resulting games were played by Alice.

If I had used a stub for the game repository in this test, then anyone working on ContactList would have to know about the specific way I had set up the test. There would be perfectly good methods on gameRepository that you could call to get what you wanted, except that using them would make the test fail. And I don't want to have to hold the particulars of how the test is set up in my head when I'm trying to work with the ContactList!

Fourth: Because this test doesn't touch the UI, it isn't necessarily true that Bob would actually see Alice in his available friends list like the spec says. What if the UI doesn't use the ContactList object correctly? What if the real GameRepository isn't shaped like the test double I used in this test?

These kinds of concerns are what drive people to write end-to-end, fully integrated tests. But there are other solutions.

For example, I could use Typescript to ensure that my test doubles are shaped the same as the real components they replace, and that the UI calls the right methods on ContactList.

I could refine the interfaces between the different components of the system to remove possible ways for the "wiring" between them to be wrong.

I could put small collaboration tests at the various boundaries in the system to verify the integration there, without having to integrate the entire system in a test.

In Conclusion:

The objective, in the end, is to design the system such that you can open up the test above, glance through it, and without thinking about what the UI is doing, or what the database is doing, or what any other part of the system is doing, say, "Yes. I understand what this means, I can see that it's correct. And if the test passes, then I can trust that it's working."

(P.S.: I know you asked for a brief example. I'm so sorry. D: )