I am currently trying to use an embedded ldap server for unit tests.
In Spring Security, you can quickly define an embedded ldap server for testing with the tag with some sample data loaded from the specified ldif.
I will be using Spring Ldap to perform ldap operations, and thinking of testing the usual CRUD features of my User service object.
Is there, however, a way to ensure that the entries in the embedded server to be in the same consistent state (sort of like a delete all and reload the ldif entries) for each test I am running?
I thought of the following:
1) Indicate that the method dirties the context, and force a recreation of the embedded ldap server, which sounds painful as it would have to restart the server for every method
2) Create the test entries in a test organization, such that I can unbind them and simply load in the ldif file again there.
I prefer 2, but it seems like the Spring LDAP has no good helpers to load and send across the content of a ldif file.
Any suggestions on how you perform ldap testing with an embedded ldap server of spring, or of the two possible solutions I mention?
Thanks
Doesn't Spring LDAP provide transactional control around LDAP operations? If so, why not use Spring test framework with its auto-rollback capability?
I also know of a JDBC-LDAP bridge driver that wraps an LDAP repository, presenting it as a relational database. I've used iBatis to connect to this (I've written this up at http://lokibear.blogspot.com, see articles from July). I've not yet tried applying transactional control, but the website for the driver mentions the ability to ignore transactions (which means you can also not ignore them...right?).
Like I say, I haven't tried this yet; but, if this provides transactions around LDAP, then you can again use the Spring test framework to get auto-rollback in place. I've put out a quick cheatsheet around that framework - see the September posts at my blog.
Sorry, I might be missing your goal here; but perhaps these suggestions are useful. Good luck!
I may be off-track here, but if you're not testing the LDAP integration itself, you could Mock out the LDAP connection with a Mock object that always returns the values you expect so that your other Unit Tests can complete.
If you're testing the LDAP connection then you're really doing an integration test. In which case it's probably best to connect to a real LDAP implementation.
You may or may not know that the embedded LDAP functionality is not provided by Spring LDAP itself, but Apache Directory Server. Unfortunately, the LDIF loader in Apache DS (as wired by Spring, anyway) has very poor error handling and reporting capability, and as such is probably not going to behave as you really want for a unit test. Your best bet if you really want to start from a clean slate each time is to take the lead of the Spring Security LDAP unit tests and reinitialize Apache DS every time, with a clean LDIF file load.
Alternatively, you could eschew LDIF altogether and construct your own unit test wrapper that verifies the pre- and post-conditions of the data prior to your unit tests running. This would be more work, but ultimately may work out better for you.
Works fine for me:
#Inject
private ApplicationContext applicationContext;
#Before
public void reloadLdapDirectory() throws NamingException, IOException{
ApacheDSContainer apacheDSContainer = (ApacheDSContainer) applicationContext.getBean(BeanIds.EMBEDDED_APACHE_DS);
LdapTestUtils.clearSubContexts(contextSource, DistinguishedName.EMPTY_PATH);
ClassPathResource classPathResource = new ClassPathResource("ldap.ldif");
File tempFile = File.createTempFile("spring_ldap_test", ".ldif");
try {
InputStream inputStream = classPathResource.getInputStream();
IOUtils.copy(inputStream, new FileOutputStream(tempFile));
LdifFileLoader fileLoader = new LdifFileLoader(apacheDSContainer.getService().getAdminSession(), tempFile.getAbsolutePath());
fileLoader.execute();
}
finally {
try {
tempFile.delete();
}
catch (Exception e) {
// Ignore this
}
}
}
I asked something similar and got an answer from Luke Taylor: Integration tests with spring-security and ldap
Related
Not sure if this will be considered a "legitimate question" or "purely opinion based", but is there a "best practice" with regards to directly testing a repository in a Spring Boot application? Or, should any integration testing simply target the associated service?
The reasoning for the question is simply the fact that, for the most part, a repository in a Spring Boot application contains no project-generated code. At best, it contains project-defined method signatures which Spring generates implementations for (assuming correct naming conventions).
Thanks...
If you can mess it up, you should test it. Here the opportunities to mess up can include:
Custom Queries (using #Query) might be wrong (there can be all kinds of logic mistakes or typos writing a query with no compile-time checking)
Repository methods where the query is derived from the method name might not be what you intended.
Arguments passed in, the type on the parameter list might not match the type needed in the query (nothing enforces this at compile time).
In all these cases you're not testing Spring Data JPA, you're testing the functionality you are implementing using Spring Data JPA.
Cases of using provided methods out of the box, like findOne, findAll, save, etc., where your fingerprints are not on it, don't need testing.
It's easy to test this stuff, and better to find the bugs earlier than later.
Yes, I think is a good pratice to do that. You could use #DataJpaTest annotation, it starts a in memory database. The official documentation says:
You can use the #DataJpaTest annotation to test JPA applications. By default, it configures an in-memory embedded database, scans for #Entity classes, and configures Spring Data JPA repositories. Regular #Component beans are not loaded into the ApplicationContext.
Link to the docs: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html
Starting from the idea that repositories should be used only inside services and services are used to interact with the other layers of the system, I would say that testing services should be enough in the majority of cases.
I would not test standard repository methods like findAll, or findBy.., they were tested already and the purpose is not to test JPA, but rather the application.
The only repository methods that should have direct tests are the ones with custom queries. These queries may be located in a shared library and it is not efficient to write similar tests across different projects(in this case regression is a big concern)
I have coded a Spring Boot based web application, which is expected to be run in WildFly server. The applications runs great, but the issue is with testing.
I have the database connections, caching and transaction management dealt by the server. Now, I need to be able to test them. While I was able to get through database connection problem through a mock JNDI connection and the transaction management, I'm not sure how to deal with testing of the caching.
One solution is to use Arquillian project. But, either this project is unable to recognize Spring Boot/ I'm doing something wrong, which is causing me pain to test the application.
Can someone please suggest on solving the issue? Below are my hibernate specific properties
spring.jpa.hibernate.naming_strategy=org.hibernate.cfg.EJB3NamingStrategy
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
spring.jpa.properties.hibernate.cache.region.factory_class=org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory
spring.jpa.properties.hibernate.cache.infinispan.cachemanager=java:jboss/infinispan/container/hibernate
spring.jpa.properties.hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.show_sql=false
spring.jpa.properties.hibernate.cache.use_query_cache=false
spring.jpa.properties.hibernate.hbm2ddl.auto=none
spring.jpa.properties.hibernate.generate_statistics=true
spring.jpa.properties.hibernate.cache.infinispan.statistics=true
spring.jpa.properties.hibernate.search.default.directory_provider=infinispan
spring.jpa.properties.hibernate.search.infinispan.cachemanager_jndiname=java:jboss/infinispan/container/hibernate
I would suggest creating a separate configuration for tests. This configuration would contain a definition of a TransactionManager bean - here is an example from other post. The next step is to provide your own implementation of TransactionManagerLookup and applying it to Transport configuration - as described in the manual.
I have a REST web service exposed at http://server:8080/my-production-ws by JBoss (7). My spring (3.2) configuration has a datasource which points to a my-production-db database. So far so good.
I want to test that web service from the client side, including PUT/POST operations but I obviously don't want my tests to affect the production database.
Is there an easy way to have spring auto-magically create another web service entry point at http://server:8080/my-test-ws or maybe http://server:8080/my-production-ws/test that will have the exact same semantics as the production web service but will use a my-test-db database as a data source instead of my-production-db?
If this is not possible, what is the standard approach to integration testing in that situation?
I'd rather not duplicate every single method in my controllers.
Check the spring Profiles functionality, this should solve the problem. With it its possible to create two datasources with the same bean name in different profiles and then activate only one depending on a parameter passed to the the JVM.
I've been looking for someone else doing this same thing, but haven't seen a scenario that's quite like this so I thought I'd see if anyone here has any good ideas on how to accomplish this.
My group builds and maintains an open-source neuroimaging data archive tool called XNAT. Previous versions of our application have always required users to run a builder application that took in a build.properties file and used that to initialize the database server configuration, among other things. We're really trying to get down to a single installable war file that we can make available on the NeuroDebian repository. In order to do this, we need to be able to start the application WITHOUT any database configuration information, run through a configuration wizard a la Wordpress or Drupal installations that includes the user inputting the database configuration, and finally setting this configuration information SOMEWHERE and re-starting or re-initializing the application context so that it gets its data source started up, Hibernate entity scans run, all auto-wired or injected dependencies that require the data source or Hibernate transaction manager resolved, and services scanned for #Transactional annotations, and so on.
I can easily see how we can use the new Spring Framework WebApplicationInitializer to detect whether the user has already set up the database configuration and initialize the app properly based on that:
If database has not been configured, create an servlet that just supports the UI for the initialization wizard
If database has been configured, create the regular application context
The problem in the first case is what happens once the user has completed the initialization wizard? We can store the database configuration somewhere and now we're ready to go but... how do we get the regular application context working? Can we just take the code that we'd call in the already initialized scenario and call that? Will that initialize the application properly then, with component scans and so on all being handled or...?
The only solution we have currently is to have the user restart the server manually (it's usually Tomcat) or use the server manager application to restart just our application. That's not very aesthetically pleasing though.
My end goal here will be to write a simple test app that takes in the database credentials and then tries to initialize everything else afterwards, but I'm hoping to see if anyone's thought about this particular issue and/or tried it and has any advice on how to handle it. Any help would be greatly appreciated!
So this is a rather "big" question, but what I'm trying to accomplish is the following:
I have a Spring application, MVC, JDBC (MySQL) and JSP running on tomcat.
My objective is to test the entire "stack" using a proper method.
What I have so far is Junit using Selenium to simulate an actual user interacting with the application (requires a dummy account for that), and performing different validations such as, see if element is present in the page, see if the database has a specific value or if a value matches the database.
1st concern is that this is actually using the database so it's hard to test certain scenarios. I would really like to be able to mock the database. Have it emulate specific account configs, data states etc
2nd concern is that given the fact that I use what is in the database, and data is continuously changing, it is hard to predict behavior, and therefore properly asserting
I looked at Spring Test but it allows for testing outside a servlet container, so no JSP and no Javascript testing possible.
I saw DBUtils documentation but not sure if it will help me in this case
So, to my fellow developers, I would like to ask for tips to:
Run selenium tests on top of a mocked database
Allow different configs per test
Keep compatibility with Maven/Gradle
I have started with an ordered autowire feature to support this kind of stubbing.
It's basically an idea that i took over from the Seam framework i was working with in the past but i couldnt find yet a similar thing in spring.
The idea is to have a precedence annotation (fw, app,mock,...) that will be used to resolve the current implementation of an autowired bean. This is easy already in xml but not with java config.
So we have our normal repository beans in with app precedence and a test package stubbing these classes with mock precedence.
If both are in the classpath spring would normally fail with a duplicate bean found exception. In our case the extended beanfactory simply takes the bean with the highest precedence.
Im not sure if the order annotation of spring could be used directly but i prefered to have "well defined" precedence scopes anyway, so it will be clear for our developers what this is about.
! While this is a nice approach to stub so beans for testing i would not use it to replace a database definition but rather go with an inmemory database like hsql, like some previous answers mentionned already. !