I have this SpringBoot server app using PostgreSQL database if it's up and sending error response if it's down. So my app is running regardless the database connection.
I would very much like to test it (jUnit / mockmvc).
My question is very simple, yet I did not find the answer online:
how does one simulate a database connection loss in SpringBoot?
If anyone wants, I can supply code (project is up at https://github.com/k-wasilewski/workshop/)
Have you thought of Testcontainers? You can spin up your docker image through a Junit test and make your spring boot use that as your database.
Since you use junit, you can start/stop this container at will.
This will generate a test which creates the condition you are looking for and write code as to what to expect when the database is down.
Here are some links to get started,
Testcontainers and Junit4 with Testcontainers quickstart - https://www.testcontainers.org/quickstart/junit_4_quickstart/
Spring boot documentation - Use Testcontainers for integration testing
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-testcontainers
Testcontainer github link example for springboot app
https://github.com/testcontainers/testcontainers-java/tree/master/examples/spring-boot
Testcontainer - Generic container javadoc. You can find methods for start/stop
container here. call from your Junit.
https://javadoc.io/static/org.testcontainers/testcontainers/1.12.4/org/testcontainers/containers/GenericContainer.html
You can implement your own Datasource based on DelegatingDataSource and then let it throw exceptions instead of delegating when ever you want to.
I've done this before by creating a Spring Boot test configuration class that created the DataSource and wrapped it in a Java proxy. The proxy simply passed method calls down to the underlying DataSource, until a certain flag was set. Once the flag was set, then any method called on the proxy would throw an exception without calling the underlying DataSource. Essentially, this allowed me to "bring the database down" or "up" simply by flipping the flag.
Related
I'm trying to translate an X12 edi message using a map created in VS2015, but I get the following error;
MapNotReady. The map '' is still being processed. Please try again later.
Running the input in VS2015 I get the correct result, but not using Azure Logic Apps
Resolved this issue by creating a new Integration account in a new Resource Group and different Location.
Looks like a bug in Azure, will log call with MS
I faced the same issue after deploying a logic app using ARM template.
What was I doing?
In deploy powershell, I was creating integration account and adding schemas and maps.
Deploying logic app using ARM template.
Immediately after deployment, I tried to execute the logic app. At that point, I received MapNotReady exception in transform action.
However after 10 minutes when I retried the message again, the problem was gone. It looks like, map service was not fully deployed.
So no need to deploy to different resource group. Probably wait for few minutes before executing LogicApps.
I would like to accesss the sitecore DB and items from console application like
Sitecore.Data.Database db = Sitecore.Context.Database
or
Sitecore.Data.Database db = Sitecore.Data.Database.GetDatabase("master")
how do I configure and setup my console application to access the DB as above?
Thanks Everyone for the suggestion, I am really interested in config changes, I used webservice, but it has very limited methods. For example, if I would like create an Item with the template and insert the item with prepopulated value, there is no such option. The reason I am looking for the console apporach is I would like to import the contents from XML or excel sheet and push those to the sitecore tree, eventually use the scheduled task to run the console app periodically. I do not want to copy the entire web.config and app_config. If anyone has already done this, could you please post your steps and necessary config changes?
You have two options I think:
1) Import the Sitecore bits of a website's web.config into your console application's app.config, so that the Sitecore API "just works"
I'm sure I read a blog post about this, but I can't find the reference right now. (I will have another look) But I think the simple but long winded approach is to copy all of the <sitecore/> element and all the separate files it references. I'm fairly sure you can whittle this down to a subset of the config required for data access with a bit of thinking.
2) Don't use the Sitecore API directly, connect to a web service that exposes access to it remotely.
There are a few of these that already exist. Sitecore itself exposes one, Sitecore Rocks has one, and Hedgehog TDS has one too. And you can always write your own (since any web service running inside the Sitecore ASP.Net app can make database calls and report values back and forth - just remember to consider security if this web service might end up exposed externally for any reason)
John West links to some relevant stuff here:
http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2013/09/Getting-Data-Out-of-the-Sitecore-ASPNET-CMS.aspx
-- Edited to add --
I've not found the blog post I remember. But I came across this SO thread:
Accessing Sitecore API from a CLI tool
which refers to this blog post:
http://www.experimentsincode.com/?p=232
which I think gives the info you'll need for option 1.
(And it reminds me that, of course, when you copy the config stuff you have to copy the Sitecore binaries into your app's folder as well)
I would just like to expand on #JermDavis' post and note that Sitecore isn't a big fan of being accessed when not in a web application. However, if you still want to do this, you will need to make sure that you have all of the necessary configuration settings from the web.config and App_Config of your site in your console application's app.config file.
Moreover, you will never be able to call Sitecore.Context in a console application, as the Sitecore Context sits on top of the HttpContext which means that it must be an application and have a valid request for you to use it. What you are looking for is something more along the lines of Sitecore.Configuration.Factory.GetDatabase("master").
Good luck and happy coding :)
This sounds like a job for the Sitecore Item Web API. I use the Sitecore Item Web API whenever I need to access Sitecore data from the master database outside the context of the Content Management server or outside of the context of the Sitecore application. The Web API definitely does not allow you to do everything that the standard Sitecore API does but it can act as a good base and I now extend upon the Web API instead of writing my own custom web services whenever possible.
Thanks to JemDavis's advise.
After I copied the configuration and made changes to config section to get rid of conflicts. I copied almost all of Sitrecore, analytics and lucene dlls, it worked great.
Only thing you have to remember is, copy the app_config folder to the same location where your dlls are.
Thanks again JemDavis....
I'm building a webapp in Go that requires authentication. I'd like to run local tests using appengine/aetest that validate the authentication behavior. However, I do not see any way to create an aetest.Context with a dummy user. Am I missing something?
I had a similar issue with Python sdk. The gist of the solution is to bypass authentication when tests run locally.
You should have access to the [web] app object at the the test setup time - create a user object and save it into the app (or wherever your get_current_user() method will check).
This will let you unit test all application functions except authentication itself. For the later part you can deploy your latest changes as unpublished google app version, then test authentication and if all works - publish the version.
I've discovered some header values that seem to do the trick. appengine/user/user_dev.go has the following:
X-AppEngine-Internal-User-Email
X-AppEngine-Internal-User-Federated-Identity
X-AppEngine-Internal-User-Federated-Provider
X-AppEngine-Internal-User-Id
X-AppEngine-Internal-User-Is-Admin
If I set those headers on the Context's Request when doing in-process tests, things seem to work as expected. If I set the headers on a request that I create separately, things are less successful, since the 'user.Current()' call consults the Context's Request.
These headers might work in a Python environment as well.
I want to make database queries in my Jersey REST webapp. The ideal situation would be to find a way where the database connection is initialised once at the first app run. Afterwards I only get the instance of DAOFactory object in my REST class and make the queries in the methods. I am using mysql connector. Is there a way to find a way to do it in Jersey? In JSF it was possible - I just used an application-scoped bean when I run the code. Moreover it would be good if I could access the ServletContext object inside this method cause I would like to use it's getResourceAsStream() method to read the database connection parameters from WEB-INF/dao.properties file. But the 'only once per app initialisation' is the crucial part here.
I have a Silverlight 4 client running on a Facebook page hosted on Google App Engine. It's using gminifb to communicate with the Facebook API. The Silverlight client uses POST calls to the URIs for each method and passes the session information from Facebook with each call.
The project's growing and it would be super-useful if I could set up a unit-testing system to make a variety of the server calls so that when I make changes I can ensure everything else still works. I've worked with nUnit before and I like what I've read of PEX but I'm not sure how to apply them to this situation.
What're the choices for creating a test system for this? Pros/cons of each?
How do I get started setting something like this up?
Solved. I did it as follows:
Created a special user account to be used for testing on the server that bypassed the authentication. Only did this on the test environment by checking a debug flag in that environment's settings. This avoided creating any security hole in the live site (since the same debug flag will be false there.)
Created a C#.NET solution to test each API call. The host project is a console app (no need for a GUI) with three reusable synchronous methods:
SendFormRequest(WebRequest request, Dictionary<string,string> pairs),
GetJsonFromResponse(HttpWebResponse response),
and ResetAccount().
These three methods allow the host project to make HTTP requests on the server and to read the JSON responses.
Wrapped each server API call inside a method call in the host project.
Created an nUnit test project in the solution. Then simply created tests that call each wrapper method in the host project, using different parameters and changing values on the server.
Created a series of tests to verify correct error handling for invalid parameters and data.
It's working perfectly and has already identified a few minor issues that have been found. The result is immensely useful and will check for breaking changes on new deployments.