Sure. Unit test where you have hundreds of signature specimens which need to be evaluated against graphics processing code. Maintaining a separate list of binary files for each resource was a mess for us. Inline base64 string in each unit test method containing the exact specimen was way more convenient. These lines are long but cause no trouble for IDE responsiveness or our github tooling.

I think maintaining a directory of binary files and using it at runtime is a lot better in the long run. Either through a separate build step which embeds them into the test binary. Or via proper env setup where tests actually know how to find the data in the file system.

At the very least you can inspect your test data easily without having to extract it from base64-encoded strings.

Current approach may be working for your team, but I can totally see why a company which has a dedicated team working on build and testing infra, prefers a slightly more complex approach. It requires one-off investment in tooling which can be payed off very soon given enough people using it.

Why does it need to be in the same test file at all? That sounds like a test resource that should be in some kind of test material/resources folder where it can be read from.

Of course you can embed binary files as base64, but have you thought if you should

An art project!

Yeah if you embed a random 100000 character art project as one liner in your code you have bigger problems than 100000 character line in your code.