Hacker News Reader

Comment by jitix | Hacker News Reader

The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy.

I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.

View on HN

Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?

Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.

Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.

Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file?

If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?

The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability.

Even when I develop in Python with multiline strings I use fixture files to better organise my code.

Edit: removed an "even" before maintainability that was part of a first draft.

This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.

Reply on news.ycombinator.com