Have you ever wondered what the best way would be to test emails? Or how you would go about testing a messaging queue?
Making sure your components are correctly interacting with each other is both a tester and developer’s concern. Join us to get a better understanding of what you should test and how, both manually and automated.
This session is the first ever in which we will have two units working together to give you a nuanced insight on all aspects of integration testing. We’ll start off exploring the world of integration testing, defining the terminology, and creating a general understanding of what phases and kinds of testing exist. Later on we’ll delve into integration test automation, ranging from database integration testing to selenium UI testing and even as far as LDAP integration testing.
We have a wide variety of demos prepared where we will show you how easy it is to test various components of your infrastructure. Some examples:
- Database testing (JPA)
- Arquillian, exploring container testing, EJB testing and more
- Email testing
- SOAP testing using SoapUI
- LDAP testing
- JMS testing
5. Testing
▪ Unit testing
▪ Integration testing
▪ System Integration testing
▪ Load testing
▪ Performance testing
▪ User acceptance testing
6. Overview
1. Testing Terminologies
2. Component Integration Testing
a. Persistence tests
b. Container tests
c. Other component integrations
3. System Integration Testing
10. Focus on terminology
▪ Dedicated test environments
▪ Sanity tests (smoke tests)
▪ Regression testing
▪ Combinations and boundaries
▪ Positive and negative
▪ Valid and invalid
▪ End 2 End testing (chain testing)
▪ Performance testing (load testing vs. stress testing)
▪ Manual testing vs. test automation
14. Persistence Tests
Using real databases for tests:
▪ slow
▪ harder than it should be
▪ separate schemas per user?
▪ network required
Using local database for tests:
▪ even slower
▪ requires (annoying) installation
▪ no network required
15. Persistence Tests
Using in-memory database for tests:
▪ super fast
▪ only lives during test
▪ allows for very specific test data
▪ can be upgraded/changed/...
20. What is a container?
A Java ecosystem in which an application is managed
life-cycle
transactions
persistence
security
...
21. What is a container?
DI container (Dependency Injection)
EJB container (Enterprise Java Beans)
Web container
Application client container
Applet container
25. Most known providers today
▪ Provides specifications for:
▪ DI container: CDI (Contexts and Dependency Injection)
▪ EJB container
▪ Web container
▪ Application client container
▪ Applet container
▪ It only runs on an application server implementing these specs.
26. What to test?
Dependency Injection (is everything wired correctly together?)
▪ Application Context
▪ CDI
31. How?
out of the box
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes =
Application.class)
@Transactional
public class SpringIntegrationTest {
Really, that easy :-) !!
36. How?
Arquillian:
▪ Embeddable containers for JUnit-tests
▪ Run tests in real running containers
The real thing application servers:
Glassfish
Jboss
Weblogic
...
37. How?
All it takes in Arquillian
@RunWith(Arquillian.class)
public class ArquillianIntegrationTest {
@Deployment
public static Archive<?> createDeployment() {
return ShrinkWrap.create(WebArchive.class, "test.war")
.addPackage(MeetingRoom.class.getPackage())
.addPackage(MeetingOrganizer.class.getPackage())
.addPackage(MeetingRoomRepository.class.getPackage())
.addAsResource("persistence-test.xml", "META-
INF/persistence.xml")
.addAsWebInfResource("jbossas-ds.xml")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
}
Actually, together with xml config, but pretty straight-forward
41. How to test ?
● Via dedicated check
FilePermission fp = new FilePermission("file.txt", "read");
AccessController.checkPermission(fp);
● Via shell scripts
Check you have staff group and file is readable by staff
[~] % ls -l file.txt | awk '{ print $1" "$3" "$4;}' | egrep -e '....r..... .*
staff' >|/dev/null && echo 'ok' || echo 'ko'
ok
● Manually...
44. How to test
● With developer controlled server
● With code
○ Spring Integration: https://github.com/spring-projects/spring-integration-samples/tree/master/basic/mail
● With dedicated tools
Eg: Sending emails could use FakeSMTP - http://nilhcem.github.io/FakeSMTP
● Running fake mail server during tests
○ GreenMail - http://www.icegreen.com/greenmail/
Roll the demo in: SendAMail project + GreenMail
https://github.com/pijalu/SendAMail.git
46. How to test ?
● Writing test code
○ ActiveMQ - http://activemq.apache.org/how-to-unit-test-jms-code.html
○ Spring Integration- https://github.com/spring-projects/spring-integration-
samples/tree/master/basic/jms
● Using tools
○ HermesJMS - http://www.hermesjms.com/confluence/display/HJMS/Home
■ Allows to post message on queues/topics
■ Observes topics !
● With containers test enabled test like Arquillian
Roll the demo in: EJBees project with Arquillian !
https://github.com/pijalu/ejbees.git
48. How to test ?
● With tools
○ Spring security
■ It can run a “test” LDAP server based on a LDIF file
○ Apache Directory Studio
■ Allows to connect and browse to LDAP server (and AD is LDAP, but weird one...)
■ Allows to run your own LDAP server for integration
■ Allows to run your own LDAP server within JUnit tests
Roll the Demo in: LDAP Dance
https://github.com/pijalu/ldapdance
50. How to test ?
● Writing your own integration tests
● Using tools
○ SoapUI
■ Can call the service
■ Perform tests
■ Can run with maven
Roll the demo in: SoapUI + SoapUI project !
https://github.com/pijalu/SoapUIDemo.git
54. Environment - Local
● typical laptop/desktop
● focus on work at hand
● not representative (resources, data volume)
● maybe even different application server
● mostly expecting unlimited resources
● limited constraints
● frequent deployments
● possibly different os
● possibly different settings (regional settings)
➔ goal: get your tasks completed
➔ target users: developer
55. Environment - Component Integration (DEV)
● more limited within company standards
● possibly increased complexity (authentication required)
● automated deployment?
● actual application server
● possible dummy systems
● mostly not load balanced
➔ goal: will it deploy on the actual infrastructure, sanity testing
➔ target users: developers
➔ challenge: bug free (and retard-proof)
56. Environment - System Integration (INT)
● representative systems
● possibly reduced data
● possibly load balanced
● whatsup
➔ goal: does it work well combined with other systems?
➔ target users: developers, testers
57. Environment - System Testing (TEST)
● representative systems
● possibly reduced data
● possibly load balanced
➔ goal: is it ready to present to business?
➔ target users: testers, functional analysts
➔ challenge: find the bugs!
58. Environment - User Acceptance Test (UAT)
● almost the real deal
● no impact on end users
● preferably identical setup compared to production
● loadbalanced
➔ goal: does it meet the business requirements we've specified? do we
need to rethink something? is this performant enough?
➔ target users: business users
64. System Integration Testing - Web application
● browser dependant
● device dependant
● subjective testing
● subject to change
65. System Integration Testing - Web application
● browser dependant
● device dependant
● subjective testing
● subject to change
66. System Integration Testing - Selenium
● target specific browser version
● browser bugs
● user simulation
● reusability
● screenshots
➔ record/replay
◆ limited usability
◆ parametrize!
➔ use static ids
➔ html only
67. System Integration Testing - Headless browser
● faster
● not 100% representative
● prepare test cases
● url check
● javascript check
● objective
➔ karma
➔ jasmine
68. System Integration Testing - When?
● funded by project
● sucky developers
● regression
● flow based applications