Does SQL Server guarantee INSERTed data is always returned by subsequent SELECTs

I am trying to determine why my SQL Server-backed, Dapper-ORM'd, xUnit-based, dotnet test-run automated tests fail 1% of the time. The tests are all some form of this:

using(var conn = OpenConnection())
    await conn.ExecuteSqlAsync("delete * from...");

using(var conn = OpenConnection())
    await conn.ExecuteStoredProcAsync("InsertSomeData");

IEnumerable<MyPoco> results = null;
using(var conn = OpenConnection())
    results = await conn.QueryStoredProcAsync<MyPoco>("GetSomeData");

Assert.NotEmpty(results);

I have 34 such tests. About 1% of the time, one of them fails but not always the same one.

A little more detail:

• The tests all share the same database instance and operate on the same handful of tables. The database is SQL Server 2017, hosted in a Linux container. The container is instantiated specifically and solely for these 34 tests. Nothing else has access to that database.
• The stored procedures are very simple -- a single INSERT with given parameters (not shown); a single SELECT with 4 joins.
• There is no intentional randomness in the tests. There is no intentional overlapping transactions.
• My first thought was that the tests were being parallelized by the test framework or runner. If the tests were to run in parallel, they would delete each others' data. However, xUnit says that if the tests are all in the same class, they will not be parallelized. All my tests are in the same static class.

All my investigation leads me to ask...

Does SQL Server 2017 guarantee that the results of InsertSomeData will be returned by my call to GetSomeData?

• If the answer is "yes", do you have a reference?
• If the answer is "no", what should I do? Wrap the call of GetSomeData with a polling, timing-out loop?