I am new to TokuMX.
Since TokuMX supports transaction managament , I want to test the same.
How to test it? Is there any use case/ sample code to test the same?
Please guide.
TokuMX's transactional semantics, including multi-statement transactions, are documented here and here, and there are more examples in this blog post.
Related
I have short question but for me important. What is better. Should we use something like factory_girl in our tests or better solution is to use simply services witch we use in our system? What is better to setup initial state of our tests.
Edit:
Thanks for answer. I have found interesting blog post in this subject:
http://blog.arkency.com/2014/06/setup-your-tests-with-services/
I think the answer in 99,9% will be: Use factories.
Here is just my thoughts:
It all depends on the services you are talking about.
If your service is quite transparent (just creates instances and assigns some fields without any logic) then you may use it in tests. Note that in this case it is likely that your service is almost a factory.
If a service contains some logic or it will ever be changed it is better to test it in isolation as well as the code that use this service. And that is when factory comes.
I have installed jclouds and I am trying to learn how it works internally.
I read all the documentation on the site and on the github but still I have lot of questions about the architecture and implementation of the jClouds.
Do you know where I can find documentation about the deep technical implementation of the framework? I am also looking information on how to add a new provider( for blobstore service)
Currently I am looking into the code but it s not always straightforward what the code does.
The best thing to do is send an email to our dev list. You can subscribe by emailing jclouds-dev-subscribe#apache.org. You can also find us on IRC at #jclouds on freenode.
Adding a new provider is quite an important change for jclouds. The first thing you'll want to do is review How To Contribute. We need to make sure it will work properly and we'll be able to properly test it so don't be discouraged by the reviews.
Having said this, a number of general considerations to take into account when starting a new provider:
New providers are added in labs first, until they are stable.
To follow the jclouds style, use a 3 space indent and a 120 character line length.
We use Guava as our core library. Try to use its utilities before adding new dependencies. In general, do not add dependencies before consulting our dev# list.
We require both live and mock tests. "mock" tests verify that the api generates the expected request according to the method annotations, and that the response is properly parsed. We use MockWebServer to do that, and you can take a look at the MockTests classes in the openstack-swift api to see an example of how these tests work.
Often the best thing to do is to copy the entire directory structure of one of the existing apis or providers and delete everything that you don't need but keep some of the files around in each directory to server as an example of how to do things. You can rename those classes and start your work from there.
Which api or provider should you choose to use as an example for your work? It depends! Please email us on our dev# list to describe the work your doing and we will recommend one. The earlier you get engaged with the jclouds community, the easier the whole process will be.
Good luck!
I would like to have additional fields in Jenkins that would be useful for reporting, for instance team names assigned to the automated tests, so that each team can clearly see their own tests.
Is it possible to add new custom fields to Jenkins reports and if so how can the field values be filled?
edit: Cut question down to make it more specific
There are no answers for this that do not involve nasty workarounds.
Instead, I will a feature request was submitted to the Jenkins project.
(updates here if and when the feature is released)
I had similar problem, and didn't find any straight forward solution. my workaround is to add it to std-out of the test, then it is possible to see it in jenkins later.
I'm curious to know how the tutorial site "Rails for Zombies" did their labs. A user is required to answer a series of lab questions by typing ruby code into (what appears to be) a command line prompt to complete each lab. Upon submitting determines if they can proceed to the next lab question.
Peeking at the DOM through Firebug, it appears they're using the canvas tag- I'm assuming this is the command line, right? Also, on the Ruby side, how do they ensure that the code entered is what was required to answer the question? Or do they just have a test setup using RSpec/Cucumber?
Any help is much appreciated. :)
For the in browser code editor we're using Mozilla Bespin, now known as Skywriter. For the evaluation on the server side we are using a sandbox to run the Ruby code, as Andy Lindeman stated. In most cases as you assumed, we're using tests to ensure the code does what you're supposed to do.
It's definitely not a simple piece of code. If you're interested in using our engine to create a tutorial of sorts, please do get in touch. Gregg at EnvyLabs.
I do not work for Envy Labs, but I'd think that the Ruby code is simply sent as-is to the server, where it's run in some sort of sandbox.
It likely works similarly to tryruby.org, whose source is freely available for your reading pleasure :)
I have been using Jira since 6months but haven;t been through any document related to various options available and how to use them for maximum output.
There must be some conventions that help in better tracking of the issue.
For instance, Logging work, Linking issues, creating sub-tasks.
It would be of help if you can share some of the features (and the conventions) that you follow while using Jira. It may vary from team-to-team but there must be some generic rules which can be followed.
Any feedback would be of help. Thanks.
Some of our conventions for using JIRA:
Each project has its own JIRA project.
We use the Greenhopper plugin for Scrum planning.
There is no development without a JIRA issue assigned. If needed, Developer add issues on their own.
Commits contain the JIRA ID (for FishEye integration).
Language of JIRA comments.
When working on an issue, it's state is changed to "in progress"
Findings, Problems, Things Done are documented as comments.
Related answer here.