Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Today folks, I wanted to talk about testing. One day we started to test a little bit differently. Why we done that and what is the consequences of that step I’ll try to tell you in a next x minutes.

Image: Three eyed character As you may know my name is Oleksiy Rezchykov I and am an Engineer. I consider myself especially after the famous book a Test Engineer. By background is mainly Java and Spring. I believe and successfully practicing XP/Agile/Lean. Also I would say that I am a Pragmatic.

Whittaker posts on GTB, year 2012 posts compiled to a book with co-authors. The Book mainly consist of Google existing practices description and recommendation. Tons of interesting stuff. One thing was particularly practically valuable for me - it is Test Size concept.

Image: Holy war, TBD Sounds familiar? Whittaker in a book describes a similar situation in Google caused by the fact that Engineers have different experiences and culture before joining the company and at some point in time company has none. When I joined Playtika this May we had a similar situation.

Small medium large tests – test division based on duration and resource usage. Each one has its purpose Test oriented, tests first approach SET, Test Engineers NO QA (Not Only QA)

Small - as small as possible. Medium a stepping stone to large – a couple of layers/services. Large end2end, real env., e.t.c. Each test size offers its own set of benefits.

One day I joined the team and suggested that we adopt the Google concept of test sizes and test run environment. And that this should be used by ALL the company through libraries, components and stuff. I was very optimistic about that The team saw in a little bit different way A lot of work has to be done.

There were no clear concept on how to name tests how to divide them

Image: Flying squirrel

Not only unit tests, poor support of Data Providers in JUnit is a sign that this kind of tests is not Unit by their nature. Main challenges – test run time, how to measure coverage, CI integration Only minor changes was done here by the team. Mainly test run time optimization. Talk is cheap but didn’t you see a unit test

Image: Happy Hippo. To go further I must give you some more insight on our services.

Image: R.P. photo from Halloween party – ask Alisa about that NOC – will call. Logging, monitoring, hard to predict all the cases but the more logging you can switch is better. AppDynamics, our own tooling. And of course Boot Actuator & CodaHale.

Image: Something which could be associated with plans or challenges, probably just a checklist or a target circle Ask Polyakov for details.

4.
Test size concept
My test is using mocks – is it still a Unit test?
I want to test concurrency, my test is using
thread sleeps – can I consider this as
Functional test?
My test which is using
in-memory DB running for
about a second –
Is it an Integration test?
@twincengray #xpdays 5

7.
Test size concept
Small tests lead to code quality.
Medium and large tests lead to product quality.
@twincengray #xpdays 8

8.
Context
Playtika facts
Founded in 2010
Multiplatform social games developer
Headquarters in Tel-Aviv
Offices in US, Canada, Ukraine, Belarus, Romania and Argentina
Industry facts
Social Casino segment is growing faster than other Social Games
segments
Mobile platforms is the main focus for developers
More about Playtika and Social Casino genre:
http://www.slideshare.net/eladkushnir/final-ccsf-elad-kushnir
@twincengray #xpdays 9

9.
Context
My team is called Infra (Infrastructure)
We are providing infrastructure (logic, which is mostly not related
to the game itself) for different games (Slotomania, Caesars Casino),
platforms (Web, Mobile) and social networks (FB, Yahoo, e.t.c.)
SOA
Services Microservices clusters
Spring Framework, SQL, NoSQL,
e.t.c.
@twincengray #xpdays 10

11.
Starting point
“Unit” “Functional” “Integration”
Present for each
service
Yes No No
Run on CI Yes No No
Coverage Depends on legacy
code %*
Some feature
acceptance cases
“Smoke” suite, tricky
cases
Environment set-up
needed
No Yes Yes
Duration Up to 35 sec** Up to 10 min n/a***
*- All new services was written using TDD so coverage was quite high
** - In some services we had to test stored procedures
*** - Those tests were heavily depending on environment configuration
@twincengray #xpdays 12

13.
A little bit more about our services
Service is a regular Spring/Spring MVC
application
Each service provides Library and Module
(Plugin) for other services to communicate with
it
REST JSON and Hessian calls are used for
communication
Configuration Service is used to load/reload
settings during start/runtime
Separation between feature toggling and user
A/B testing
New services are developed using Spring Boot
@twincengray #xpdays 14

14.
“Functional” to Medium tests
So called “Functional” tests
Were not run on CI
Required pre set up environment (DB’s)
Service started in a standalone container
External “fake” Configuration Service is used
Duration - up to 5min
@twincengray #xpdays 15

15.
“Functional” to Medium tests
Our improvements
Generally we are trying not to test anything that does not belong to
specific service
DB migration to prepare DB’s state anywhere anytime
Meta information about the environment needed
No external processes - embedded container and Configuration
No @DirtiesContext
@twincengray #xpdays 16

16.
Medium tests as we have them now
Concurrency tests
Cache tests
Service Configuration testing
Service API testing
Service module/library testing
Persistence layer testing with real life data
Time - less than 2min
@twincengray #xpdays 17

18.
“Integration” to Large tests
So called “Integration tests”
Integration tests used Docker to store “production snapshot”
Was not run on CI
Not any computer could handle such a large image
Each small change required some efforts updating the image
@twincengray #xpdays 19

25.
Plans/Challenges
Test run infrastructure
Load tests for ALL pain points to be run on regular basis
Back-up compatibility tests (Modules/Libraries vs Services)
Make large tests run automatically
Test results specified in artifact metadata
Environment provisioning in real time using TC as trigger
@twincengray #xpdays 26

26.
Summary
Testing is needed on all application levels
Each level of testing has it’s own goal
It us useful to group tests according to the run time and not only the
test context
Opensource your code in the organization
If your code could be used elsewhere compose a library and write a
HOWTO Wiki page
Check Wiki before writing code
Do not reverse your testing pyramid
Improve, innovate, improvise
@twincengray #xpdays 27