For testing purposes I would like my test function to return exactly what the file contains.

For tests, I think either of what you showed is ok, plus the variations shown by the others. Here are my comments on various ways to get multiline data, in particular data for tests:

• Here docs are probably one of the most common ways to get multiline strings. One minor potential caveat is that line endings in here docs are always \n's. If you want to explicitly test different line endings, then I recommend qq strings instead and explicit backslash escapes (\n, \r, etc.) instead of literal line breaks. Also, if indented here docs are desired, properly unindenting them in Perl before 5.26 requires a bit of extra code.

• Multiline strings work, although PBP recommends against them (ProhibitImplicitNewlines).

• __DATA__ is another alternative, one potential caveat to remember here is that DATA is the filehandle that is used to read the Perl source file, so for example if you've got use utf8;, that remains enabled when reading from __DATA__ (unless changed with binmode). Plus, if you want to get multiple multiline strings from __DATA__, you'll have to split them yourself or use a module for that (e.g. Inline::Files, though that's a fairly powerful module).

• Of course, you can always use actual files. Personally I often generate them using functions like this, and as mentioned above, using qq{} strings and backslash escapes so that I have full control over what the files will look like.

• Though I wouldn't recommend this for embedded test data, sometimes there may be instances where you want to test something that's part of the POD documentation. For example, as part of my author tests I often test code snippets from my POD like this (I've even written a fairly complex parsing module, though I now think that's only worth it if there's a lot of code in the POD).

Also note that if you need filehandles, you can use in-memory opens, which are relatively performant at splitting strings into lines.

open my $fh, '<', \<<'EOF' or die $!;
Hello
World
EOF
[download]

Also note that if you need filehandles[...]

I have wanted to do this before but didn't know about this feature. Thank you!

Maybe cleaner, or maybe not ...

#!/usr/bin/perl

use strict;
use warnings;

use Test::More tests => 1;

print "-------\n";
print json_q();
print "-------\n";
print json_here();
print "-------\n";

is(json_q(), json_here(), "should be the same");

sub json_q {
q(      "Type": 0,
      "Width": 504,
      "X": 18,
      "Y": 18
    }
  ]
});

}

sub json_here { <<'END_JSON' =~ s/\n\z//r }
      "Type": 0,
      "Width": 504,
      "X": 18,
      "Y": 18
    }
  ]
}
END_JSON
[download]

sub json_here { <<'END_JSON' =~ s/\n\z//r }

Although I'd probably have done something similar, I just wanted point out that s///r requires Perl 5.14+, which may be a limitation if this is a module that is intended to be compatible with a broad range of Perl versions. sub json_here { chomp( my $json = <<'END_JSON'); $json } works fine too.

tybalt89, you are one of the most unorthodox Perl hackers I've seen so far and I mean it as a compliment. :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

UPDATE

WOW, this even allows interpolating variables from the function scope in the "outside" HERE-DOC ...

use strict;
use warnings;

print "-------\n";
print json_here(42,666);
print "-------\n";


sub chompit {
    my $str = shift;
    chomp $str;
    return $str;
}


sub json_here { my $x=shift; chompit << "__JSON__" }
      "Type": 0,
      "Width": 504,
      "X": $x,
      "Y": $_[0]
    }
  ]
}
__JSON__
[download]

C:/Perl_524/bin\perl.exe -w d:/tmp/pm/chomp_here.pl 
-------
      "Type": 0,
      "Width": 504,
      "X": 42,
      "Y": 666
    }
  ]
}-------
[download]

Because it's a lexer thing. To the parser it's just a string *inside* the body of the sub.

Purely out of esthetical reasons

use strict;
use warnings;

print "-------\n";
print json_here();
print "-------\n";


sub chompit {
    my $str = shift;
    chomp $str;
    return $str;
}


sub json_here {
    chompit << '__JSON__' ;
      "Type": 0,
      "Width": 504,
      "X": 18,
      "Y": 18
    }
  ]
}
__JSON__
}
[download]

update

changed END_JSON to __JSON__

• I like naming the HERE-ID after the format, that's a plus and can help the IDE with formatting
• But I don't wanna read END_ at the start
• Surrounding underscores are a (my?) visual anchor to recognize a here doc

I like your suggestion to not use 'END' at the start of the here-doc. Showing the format is a great idea. This made me wonder what would happen if I used '__DATA__'. It actually worked!

The 'file' which you are simulating almost certainly has a newline at the end of every (including the last) line.

In fact it doesn't. At least you only said 'almost' certainly. LOL. The json file is part of an archive that is exported from my phone. I wrote a text extractor to get all my memos from these archive files. The json file it extracts has no newline on the last line hence this discussion.