Are SQL unit tests supposed to be so long?

I am writing stored procedures with some non-trivial business logic. I am trying to unit test them, but the actual tests end up being quite long (shorter ones starting at 40-50 LoCs, using commonly 4 different tables), which doesn't seem very "unit". (Admittedly, I format my code in a way where it takes a lot of space.) In context of "normal" programming languages I've heard the advice to refactor the complex procedure into smaller chunks. But I don't want to do that here because: 1. I don't want to pollute "global namespace" by small routines called from one place only. 2. Passing around tables from and to stored procedures is cumbersome. 3. Custom functions can have negative effects on performance. Am I wrong about this reasoning? I am new to unit testing, so perhaps I am just writing my tests wrong? Is SQL longwinded language and thus it's unit tests are longer as well? *** (I am using SQL Server with tSQLt framework, but I believe the question is system-agnostic.)