I am trying to test a functionality, which inserts few details into the DB. In the test.log, it shows the insert command that is generated and also the log messages that I have placed to show the progress and everything seems to be working fine except the actual data is not getting inserted into the DB. I am checking whether data is inserted in db/test.sqlite3. No exception is generated when the test cases are run. Is there a setting, which I have to set inorder to insert data into the test DB? or am i missing anything else
Thanks
Are you checking the database after the test is run?
By default Rails runs all tests usings transactions. This means after each test is run, the database is rolled back.
This is preferred for testing. Otherwise you may have one test tainting the data or state which affects another test.
Test data is usually cleaned up. Once the test cases are run. So I don't think there is anything in a test database. After each test transaction is run, the database is rolled back.
Related
Having an entity with a date field inserted/updated via a SAPUI5 dialog. After some consecutive updates (changes on the date via the datepicker) on the same record, I experience this weird error. I say weird because I don't have this kind of check inside my update entity. In fact the update entity method does nothing more than performing a couple of simple checks in other fields and eventually inserting the record, no calls to BAPIs, standard SAP function modules or anything. Also weird the fact that it doesn't happen always. Spent half the day repeating the same motif, just consecutive updates with debug, sometimes it happens, sometimes not. No exception occurs in my method, error comes from standard SAP after the end of get_entityset which follows the update. If helpful, I attach a snapshot of the batch operations involved.
Batch operations table
And it gets better! After the application crashes, never opens again, it actually produces during the load of the initial worklist (get_entityset method) a variation of the aforementioned error (Message E FK 080 cannot be processed in plugin mode HTTPS). Application stops crashing...as soon as I delete the record from the database.
Record looks just fine in SE16N and gateway client works fine when I test the get_entityset method. Cleared all cache in the system (used this: https://blogs.sap.com/2016/03/02/cache-maintenance-in-fiori/), cleared even the browser cache (yeah, I know that doesn't make sense) but problem persists. I use model.submitChanges to update, no change groups involved.
Does this ring any bells to anyone?
Best regards
Greg
I understand cucumber and capybara are to mimic user actions to test web application. However, is it possible or recommended if I directly to fetch db record to have a test if some attributes are unable to find from web interface directly?
If yes, how to locate the db record created by current test case?
It's not recommended, but is possible, to do direct database access tests in feature tests. The main reason for this is that feature tests are intended to be black box tests that test a specific feature in the application from a users experience perspective (and users can't see into the DB, well shouldn't be able to anyway). In that case even though the value of some attribute of an object isn't technically visible in the UI the attribute has to have some effect on the record when shown (otherwise why have the attribute in the first place), and that effect should be testable via the UI.
In the rare cases where you do actually need to do direct database access you need to remember that you need to control synchronization between the UI and when you test the DB. For example the following test code would lead to at best flaky tests.
...
click_button('Do something')
expect(MyObject.last.some_attribute).to be true
...
This is because once the button has been clicked Capybara doesn't know about any further actions that click creates, and just returns. Then the DB access occurs before the request generated by the button click is processed and either there is no record yet, you're testing against the wrong record, or the state of the record hasn't been updated yet and the test fails. To fix this you need to insert an expectation between the click and the DB check to wait for the triggered action to finish
...
click_button('Do something')
expect(page).to have_content('Something has been done') # UI check that will succeed when the triggered action has completed
expect(MyObject.last.some_attribute).to be true
...
As for how to identify the DB record you want, you control all the test data, and it should be reset for every test. That way if you've just created a record it should be the last record (MyObject.last). If you're editing a record then you created the initial record in the setup for the test and should have access to it (my_test_object.reload...), etc...
I use TFS 2010 and I need using TFS API to retrieve an information about work items that were deleted. There is a table [WorkItemsDestroyed] in the TFS DB that contains the information about destroyed work items. Is there any way to get that information using TFS API?
It depends on what information you want to retrieve. If you want to find out who deleted the work item then you can do that with sql (#pantelif comment).
If you want to retrieve information about the work item itself I think there is not any way to do that, either from TFS API or sql command. As described at this post, you cannot recover deleted work items:
Deleting Work Item Action Is Not Recoverable
Actually, as long as the test plan has not been deleted, there should be full history of the actual test results allowing you to recover from the deletion of a test suite...it may take a bit of time, but process works.
Try this to re-create your test suites and associated results.
Recreate the suite.
Add tests if not a query-enable suite.
From Test tab, select your suite within the hierarchy.
Create some initial results to allow you to see full history for each test. Within the test lists pane, mass-select all test results and set them to blocked.
Now when you open each test result, you will see full list of previous test results history associated to each test case at the bottom of the results window.
In other words, you need to trigger an initial result to see the full history.
For any results only carrying a single “Blocked” result, the test has not been executed. (first time the result has been made)
For tests that have additional results associated to it, identify the last known state (see the Created date column), then set it appropriately (Pass/Fail/Blocked)
NOTE: This will only work as long as the Test Plan has not been deleted. If it is simply a test suite, this should get you back up and running quickly.
Is there a way to save the 500/404 etc errors to your database so you can check them to see if there are any bugs on the site?
I thought you could send an JS AJAX request from the 500.html page. e.g.
/errors/create/?message=error_message&ip=123&browser=ie9
But I'm not sure how to get that information when running in production mode?
Any help greatly appreciated,
Alex
This is what I have in my application controller:
def rescue_action_in_public(exception)
#This is called every time a non-local error is thrown.
#Copy the error to the db for later analysis.
Error.create :exception_name => exception.exception.to_s, :backtrace_info => exception.backtrace.to_s
#Then handle the error as usual:
super
end
As you can see I have an Error model I created and this saves a new one to the DB whenever it happens. One thing to remember is that backtraces are much to big for string columns so you will need something bigger like a text type. This works in my Rails 3.0.5 app.
Logging errors to the db is inadvisable since these errors can often be caused by database issues. It's safer to append your errors to a file (on a separate disk) if your site is high traffic, if the file system is unresponsive, then your db won't work anyway. Even safer would be to use an asynchronous message queue hosted on another server. In both cases, you can create reports by periodically parsing your log output.
I have created a rake script to send e-mails to some users.
The rake script first needs to delete some old database records, and then proceed with the e-mails.
The trouble is that during the time that the script is running, some users may view/delete the data themselves. If the data is deleted by the script, then the views should be refreshed, in order to accommodate the new data.
The first obvious solution that I can think of is to never display the old data in the views , and so avoid the possibility that a record is deleted after it has already been deleted.
But I still think that I have a race condition possibility here, and I would like to know how could I lock the database while executing the script.
I am using Mysql as my database system.
I would approach this by setting up a rake task that calls a method on a model to delete the database records. I would then wrap the code to delete the old mails in a transaction. That will lock the database while deleting the emails and allow you to handle any exceptions thrown when anyone else tries to delete the data.