More readbale way to test JSON parsing - ruby

I'm writing a program in Ruby that is parsing a fairly large JSON file. I'd like to be able to run a piece of Ruby code (in a testing environment) that parses this file, and see the information that has been extracted in a readable "pretty print" kind of way, for the sole purpose of testing.
So far I've just been testing things using irb in the terminal, but the output has no formatting whatsoever, so it's very difficult to figure out if things are working correctly. Is there a tool that makes JSON parsing a bit less painful?

awesome_print is a very convenient gem for this purpose. And about the REPL, I suggest to use pry instead of irb.

I suppose you are using json from the stdlib?
Anyhow, you can test your code with minitest or rspec. I would not test for readability of your output, but rather test that given an input X, you get expected output Y.

You can copy and then paste a JSON object string into a code cleaner like http://www.dirtymarkup.com/ which will re-format the code into a more readable format.

Related

How to embed ruby variables in cucumber.feature tests

I have following cucumber test
Scenario Outline:
Given site <url> is available
Then I see all all content
Examples:
|url|
|"google.com|
In the test case is dynamic and is generated in ruby code.
Problem:
I want to replace google.com with a ruby variable e.g., <%URL%>. Is that possible to embed ruby code in cucumber tests and evaluate ?
I think you should not do that on the feature steps. If you need a ruby variable here it means that you are doing something wrong. Check some examples around
Link here
The features should be clear text so anyone can read, specially non-programmers. so that is why you should now start mixing code with features. The code goes behind, in your step definition.
You can eval this string it if you trust code in this feature file. But it may be a bad idea for the reasons outlined by #SnakeSanders.

Using Rspec 2 to test a command line application's UI layer

I'm writing a command-line application in Ruby. I'm rather familiar with Rspec 2, as it's used in some Rails applications I'm working on. I'm writing a command-line application and I'm attempting to use Rspec 2 for BDD.
How can I test the user interface layer of my application? I need to give the application interactive input, or check for certain output printed using puts. Also, is there any way to suppress the STDOUT output? When I run autotest, the output of my application gets printed between the status outputs of rspec, making it extremely hard to read.
Here's an example that should help you. I use it in one of my apps that I test with Minitest, but it should be easy to translate to Rspec.
def setup
$stdout = StringIO.new
...
end
This gets rid of the app's output in between the test results, since stdout will be written to a StringIO object. The same way you can also test if something specific got output, since you can check the StringIO object against regular expressions.

What a Ruby parser would you suggest to parse Ruby sources?

A parser I'm looking for should:
be Ruby parsing friendly,
be elegant by rule design,
produce user friendly parsing errors,
user documentation should be available in volume more than a calculator example,
UPD: allowing to omit optional whitespaces writing a grammar.
Fast parsing is not an important feature.
I tried Citrus but the lack of documentation and need to specify every space in rules just turned me away from it.
Treetop
Ragel
Or in case you want to parse Ruby itself:
parse_tree and ruby_parser
Edit:
I just saw your last comment about needing a subset of Ruby for your project, in that case I'd also recommend having a look at tinyrb.

how do I process a readme file with rdoc to display ruby script help/usage info

I'd like to keep my usage documenation in a readme file (duh) instead of comments at the top of my script. How do I get RDoc::usage to pull the usage information out of the readme instead of the script comments?
RDoc is designed to parse a source file, look at the comments and their locations, build cross-references of the variables, and, when done, tie it all into a decent output. Because RDoc is designed to work against source files it might not be the best choice for what you want to do.
Instead you might want to look into Yard, which is tag-based. Can I get my README.textile into my RDoc with proper formatting? has some useful information for you too.
In either case, if you can't get the app to parse a README-type doc like you want, you might be able to spoof it by putting all your docs in the file, along with class and method stubs so the parsers can grab the parameters, globals, and other "whatnot" they need to create usable documentation.
Otherwise, you'll probably have to forgo using the automated help and type it all in.
My recommendation is to do it the RDoc way, and document inside your code. It's not hard to do at all, and the output can be very satisfactory. It's pretty amazing how good a job RDoc can do.
I'm certainly not experienced enough to tell you the answer, but please allow me one piece of advice.
Most of the developers are unlikely to ever update the documentation even if it's 3 lines of code above the implementation.
Do a favor and don't make the process even harder.
Keeping general documentation separate is a nice idea though, but it has nothing to do in your RDoc-generated output anyway.

Using RDoc and Executing Code - Annotating

I have a series of Ruby methods andI would like to dump their return values out to a formatted report. However, I'd also like to annotate these results (i.e. with descriptions of what the value is), and I was wondering if I could use the existing comments on each method to do this annotating?
So I guess what I want to do is output the rdoc as normal but for each method actually run the method with an argument. The argument is the same for every single method, which simplifies it.
with 1.9 there is a Method#source_location that might be helpful for you (ripper might help,too).
Also note: http://github.com/rdp/arguments might be helpful

Resources