By default, RSpec's output ends with something like
14 examples, 0 failures
Is it possible to show the number of assertions made along with this stat, similar to what other libraries provide?
There's no support for that. If you're interested in it, please feel free to submit a feature request at https://github.com/rspec/rspec-core/issues.
It's a good habit to have only one assertion per example spec.
Related
I'm just learning the Jasmine library, and I've noticed that Jasmine has a very limited number of built-in assertions. I've also noticed that, despite having such a limited number, two of its assertions appear to be redundant: toBeDefined/toBeUndefined.
In other words, both of these would seem to check for the same exact thing:
expect(1).toBeDefined();
expect(undefined).not.toBeUndefined();
Is there some reason for this, like a case where toBeDefined isn't the same as toBeUndefined? Or is this just the one assertion in Jasmine that has two perfectly equal ways of being invoked?
One might assume the same for toBeTruthy and toBeFalsy, or toBeLessThan and toBeGreaterThan (although I guess the missing assert from the last two is toEqual). In the end it comes down to readability and user preference.
To give you a more complete answer, it might be useful to take a look at the code that is invoked for these functions. The code that is executed goes through separate paths (so toBeUndefined is not simply !toBeDefined). The only real answer that makes sense is readability (or giving in to annoying feature requests). https://github.com/jasmine/jasmine/tree/main/src/core/matchers
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.
Is there a tool that parses a Ruby script (MRI/YARV) and gives statistics of how many lines each module/class/method definition is?
Saikuro will do this. It's also included in metric_fu, which makes it easy to run Saikuro and many other code metrics tools.
(Be careful, the saikuro gem is probably not what you want, instead it's Saikuro with a capital "S".)
What do you mean by MRI/YARV? A script doesn't have an implementation associated with it. The tool may be associated with a particular implementation, though.
There may be such a tool in the code metrics section of Ruby Toolbox.
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.
When adding internationalisation capabilities to an Oracle web application (build on mod_plsql), I'd like to interpret the HTTP_ACCEPT_LANGUAGE parameter and use it to set various NLS_* settings in the Oracle session.
For example:
HTTP_ACCEPT_LANGUAGE=de
alter session set nls_territory=germany;
alter session set nls_lang=...
However, you could get something more complicated I suppose...
HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5
How have folks tackled this sort of thing before?
EDIT - following on from Curt's detailed answer below
Thanks for the clear and detailed reply Curt. I didn't really make myself clear though, as I was really asking if there were any existing Oracle widgets that handled this.
I'm already down the road of manually parsing the HTTP_ACCEPT_LANGUAGE variable and - as Curt indicated in his answer - there are a few subtle areas of complexity. It feels like something that must have been done many times before. As I wrote more and more code I had that sinking "I'm reinventing the wheel" feeling. :)
There must be an existing Oracle approach for this - probably something in iAS??
EDIT - stumbled across the answer
While looking for something else, I stumbled across the UTL_I18N package, which does exactly wham I'm after:
Is there an easy way to convert HTTP_ACCEPT_LANGUAGE to Oracle NLS_LANG settings?
Sure, and it's not too tough, if you break up the problem properly and don't get to ambitious at first.
You need, essentially, two functions: one to parse the HTTP_ACCEPT_LANGUAGE and produce a language code, and one to take that and generate the appropriate set commands.
The former can get pretty sophisticated; if you're given only 'en', you probably want to generate 'en-us', you need to deal with chosing one of multiple choices when nothing matches perfectly, you need to deal with malformed header values, and so on. Don't try to tackle this all at once: just do something very simple at first, and extend it later.
The same more or less goes for the other half of it, generating the set commands, but this is pretty simple in and of itself anyway; it's really just a lookup function, though it may get a bit more sophisticated depending on what is provided to it.
What will really make or break your programming experience on something like this is your unit tests. This is an ideal problem for unit testing and test-driven development. Unit tests will make sure that when you change things, old functionality keeps working, and make it easier to add new functionality and fix bugs, because you just add another test and you have that to guide you from that point on. (You'll also find it easier to do a complete rewrite of one of the functions if you find out you've gone terribly wrong at some point, because you can easily confirm that the new version isn't breaking anything.)
How you do unit testing in your environment is probably a bit beyond the scope of this question, but let me add a few hints. First, if there's a unit test framework ("pl-sql-unit?") available for your environment, that's great. If not, don't panic. You don't need anything sophisticated: just a set of inputs and expected outputs, and a way to run them through the function and either say "all OK!" or show any incorrect results. You can probably write a single, simple PL/SQL function that reads the inputs and expected outputs from a table and does this for you.
Finally stumbled across the answer. The Oracle package UTL_I18N contains functions to map from the browser language codes to Oracle NLS settings:
utl_i18n.map_language_from_iso;
utl_i18n.map_territory_from_iso;
The mapping doesn't seem to cope very well with multi-language settings, e.g. en-us,en;q=0.5, but as long as you just use the first 5 characters the functions seem to work ok.
HTTP_ACCEPT_LANGUAGE: ar-lb,en-gb;q=0.5
v_language:
v_territory:
HTTP_ACCEPT_LANGUAGE: ar-lb
v_language: ARABIC
v_territory: LEBANON