How to pretty print the query results after calling fetch()? - jooq

I use fetch() and i get a org.jooq.impl.ResultImpl instance.
How to print them in nice way? Without me specifying the fields names(get the header from result)
Something like this :
+---+---+
| f1| f2|
+---+---+
|foo| 1|
|bar| 2|
+---+---+
I want something with header on top (even if a field name is duplicated), and the row results bellow.
I tried some methods from ResultImpl but i haven't found it yet.
intoMap() is nice but it complains when duplicate fields.
I also tried intoList() but this way i get only the values, without the field names.
I want both header and rows, like the show() method in Apache Spark.

The simplest way to get this formatting is to just call Result.toString(). It calls through to Result.format() with a few sensible defaults for debugging. If you want to be in control of the formatting options, just call Result.format() yourself.
See also the manual section about formatting text.

Related

How can I display multiple line scenario text in extend reports?

In my feature file, using the same scenario I am checking more than one requirements. I have written the scenario like below:
Scenario: My first requirement ID
My second requirement ID
My third requirement ID
Etc
After execution, the extend report shows only the result as
Scenario: My first requirement ID
How can I get all the three I D,s in extent report.
NOTE:Each of my scenario title is lengthy.
Can you explain your scenario text a little bit more? According to the documentation, the scenario should describe in human terms what we expect the software to do. It is quite unusual to include expected data in that scenario text. Are you using the ID from an enum? If that is the case, it would be better to spell out the enum in human readable terms. Scenario: UserType is Administrator for example. Another option would be to use a Scenario Outline, something like
Scenario Outline: My generic requirement statement
Given Id <whateverId> is provided
When I do <activity>
Then I expect to see <result>
Examples:
| whateverId | activity | result |
| 12 | firstMethod | MyResult |
| 20 | secondActivity | anotherResult |
| 42 | thirdExample | thirdResult |
The variable names provided in the outline in angle brackets become the column headers in the examples grid. Just be sure to indent the grid below the Examples: line and also include the pipe | on both the left and right boundaries of the grid. Hopefully that helps.

How much data should be given in a cucumber feature file?

I'm trying to write some Gherkin feature files in order to do BDD acceptance testing using SpecFlow. The system I'm trying to test consists of multiple RESTful APIs - system has a microservice architecture. In a scenario, I need to be certain that some records already exist in the database prior to going with the actual scenario, so I've included a Background section with a given part. The problem I'm having is that each of those records that need to exist are created through APIs that require lots of data in their schema contact and the team requires that I specify each and every fields and their respective values in a record in a gherkin table. The result is something like this:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
This is the header of one of my tables which is going to be used to create a Traveler record in the database before starting the actual test by specification. However, as you can see this table has too much fields and therefore is too long too fit on the screen and thus very hard to read and maintain. secondly it's tightly coupled to the DTO schema. I argued that we shouldn't put this much detail on our specificatons, trying to include only vital high-level data (e.g. given we have an existing traveler named "James Peterson") but the team and the CTO insisted that these details should be present on the feature file. In my next attempt, I broke the tables into multiple tables (e.g. personal data, order data, passport data, etc.).
But I'm still confused and I think I'm still not doing the wrie thing. What's your recommendation? Do we have any rule of thumb or best practices for this?
Can you transpose the filed and values in the data table as below.
|field |values |
| PassportExpireDate |[] |
| PassportNumber |[] |
| PassportCountry |[] |
| Firstname |[] |
| Lastname |[] |
| LocalFirstname |[] |
| LocalLastname |[] |
| Birthday |[] |
| NationalNumber |[] |
| NationalityCountryId |[] |
| PassengerType |[] |
| Gender |[] |
| PartyId |[] |
| SourceTravelerId |[] |
| CellNumber |[] |
| Price |[] |
And in the step def implement the logic to get the values from the values array.
Specflow supports external data binding for such cases. You can use Excel binding to keep your feature file fit.
Scenario Outline: Add Traveler
Given ...
When ....
Then ....
#source:TravelerRecordsExamples.xlsx
Examples:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
TLDR None
Don't put definitions and data in a Gherkin tables, its incredibly counter productive and error prone. Instead use something else to specify the fields (ideally the source code of the api) and name each thing.
Then use simple Givens to create you things.
Now in your case you seem to be creating travelers. The behavior your Gherkin is documenting is the creation of travelers. HOW travelers are created and what their characteristics are have no place in this description of the behavior.
So your background steps become something like
Given there are foo travelers
an the implementation is something like
Given 'there are foo travelers' do
create_foo_travelers
end
and now you have translated you problem from
from
How do I do something incredibly stupid and difficult in Gherkin
to
How do I write some code to create travelers
This is the approach you should take to writing all scenarios when Cuking. The scenario should only document the WHAT and WHY of the behavior. Any details about HOW the behavior is implemented have no place in the scenario.
The true power of cuking is using natural language, naming and abstraction to make you cukes simple. Use these skills to delegate the complexity of HOW to more appropriate tools.

Where is a list of *all* Spark property keys?

Where is a list of all (valid, built-in) Spark properties?
The list of Available Properties on the official Spark documentation does not include all (valid, built-in) properties for the current stable version of Spark (2.4.4 as of 2020-01-22). An example is spark.sql.shuffle.partitions, which defaults to 200. Unfortunately, properties like this one do not appear to be accessible via any of sparkConf.getAll(), sparkConf.toDebugString(), or sql.("SET -v").
Rather, built-in defaults appear to be accessible only by explicit name (i.e. sparkConf.get("foo")). However, this does not help me since the exact property name must be already known, and I need to survey properties that I don't already know about for debugging/optimization/support purposes.
you can use.
sql("SET -v").show(500,false)
Which will give you a near complete list not including the internal properties.
+-----------------------------------------------------------------+-------------------------------------------------+
|key |value |
+-----------------------------------------------------------------+-------------------------------------------------+
|spark.sql.adaptive.enabled |false |
|spark.sql.adaptive.shuffle.targetPostShuffleInputSize |67108864b |
|spark.sql.autoBroadcastJoinThreshold |10485760 |
|spark.sql.avro.compression.codec |snappy |
|spark.sql.avro.deflate.level |-1 |
...
I don't think this is the complete answer, but it can help. It will show more properties than your alternatives. At least will show options modified by some kind of middle ware, like Livy.
Set this parameter:
spark.logConf=true
Now all your session configuration will be saved in yarn log at level INFO. Do a yarn logs -applicattionID <your app id> and search for spark.app.name= to find your session properties.
Another problem is that you will see the properties values just after executing the job.

complex console.log output in cli

I'm creating informational output with console.log() in Node.js however, I would like to create a split screen that somehow outputs different data.
Example:
---------------------------------
| value a.1 | value b.1 |
| value a.2 | value b.2 |
| value a.3 | value b.3 |
| value a.4 | value b.4 |
| value a.5 | value b.5 |
| | value b.6 |
| | value b.7 |
---------------------------------
It could be that value b.x is updating very fast, and value a.1 very slowly.
What could I use? Maybe something else then console.log()?
UPDATE:
I needed a UI library for the console.
It sounds like you want a UI library for the console. You're in luck. This sort of thing has been around for a while.
You essentially have two choices:
https://github.com/chjj/blessed - A simple graphics library for terminals that lets you do stuff like what you're describing above.
https://github.com/mscdex/node-ncurses - node bindings for ncurses (this is a standard terminal graphics library).
I think blessed has a nicer API, but the choice is yours!
For the sake of others looking around for more options:
Along with blessed and node-ncurses, you have Colors, Chalk and Terminal-Kit as well.
However, if one do not want to use console.log(), Terminal-Kit could be of use.

Is it possible to use 2 different examples table in Cucumber/Cuke4Duke

Is it possible to somehow construct a Scenario which uses two different Example tables in different steps? Something like this:
Given I log in
When I view a page
Then I should see <goodText>
Examples:
|goodText|
|abc|
And I should not see <badText>
Examples:
|badText|
|xyz|
The scenario above doesn't work, also in reality there would be more rows to each table.
It looks like you're confusing tables with scenario examples. You can mix them, but from your example I'm not sure what you're trying to achieve. Why not just write:
Given I log in
When I view a page
Then I should see "abc"
But I should not see "xyz"
or if you wanted to check for multiple strings:
Given I log in
When I view a page
Then I should see the following text:
| abc |
| def |
But I should not see the following text:
| xyz |
| uvw |
You say that in reality there would be many more rows to the table; but of course a table can also have many columns.
Would this not work for you?
Given I log in
When I view a page
Then I should see <goodText>
But I should not see <badText>
Examples:
|goodText| badText |
|abc | xyz |

Resources