1. Slide 1
• Automated tests for the ever-changing business
• Mikael Lundin
• Emil Birgersson
• Twitter backchannel
• Questions, difficult words
--------------------------
Welcome to our presentation about testing and automation in web development.
Please, if you have any questions, if there's a word you don't know or whatever,
don't hesitate to ask, we have time.
1

2. Slide 2
Read headline - Explain what you mean
Even though you work ”agile”, your development process might not be.
Need the right tools to be truly agile
Lets look at some problems that may appear in software development
-------------------------------
Todays business has to make fast decisions and they need the response time in their
organization to be as low as possible. That’s where problem arises if the software
team building and supporting the business systems are not agile enough to handle
change.
As we all know, change is death to any system. Or does it really has to be like that?
What if we could introduce to you, tools that make changes easier and does not
include months of bug testing before going live. We want a development process
that can handle requirements on the fly and does not get stuck with with one of the
following problems:…
2

3. Slide 3
• Explain the picture
• Several developers working on the same code
• Committed code, not complete
• Project does not build straight from repository
• Time consuming, stalling the project
• It works on my machine provides little comfort in that situation
--------------------------------
Some of you might be familiar with this type of situation. Usually there’s one or a
couple of developers who is most active when is comes to committing code into the
repository. Any problems with the source code does not reveal themselves until
someone else is going to work on the project and it turns out that the project does
not build straight from the repository.
This is a real problem, we know because we've been there and we know how
frustrating it can be when you need to work on a project and it turns out that there
are missing pieces of code sitting on a laptop somewhere in the world.
3

4. Slide 4
• Explain the picture
• For every new version complexity grows
• Example: Big corporate site + web shop
• In a system everything relates to something else in the system
• Break old functionality
--------------------------------
For every change to a system, for every new version, complexity grows. And for
every added functionality it becomes harder to keep track on old functions. When
you add a web shop to an existing corporate site, it is easy to just test that new
functionality. But this is a system, and a system is functionality that somehow relate
to each other. Even if what you add is something totally new, it may actually break
old functionality. And how unlikely it may seem, you must make sure that the old
stuff still works when you add something new.
”But our site is huge, it would take hours to make sure all the old stuff work. We
can’t do that every time we release some new function.”
No, no you can’t test all the old functionality every time you add something new, but
you have to!
4

5. Slide 5
Explain picture
• Worked like crazy to meed deadline
• After a while, realize that release was start of long bug correcting process
• Developers have gone off to other projects
• Lets look at some solutions…
--------------------------------------------------------
Here's another problem which some of you might be familiar with. So you've all
worked like crazy to release your project on time and it looks like you've made it.
After few weeks or even months later you realize that the release was in fact the
start of a very long and tedious process of correcting errors and bugs.
Another problem is that the people who most actively developed the original
solution probably went on to other projects, leaving this poor guy over here with a
ever growing list of bugs/corrections.
Ok, so now we've looked at some problems in the software development process,
let's look at some tools that can help us solve them.
5

6. Slide 6
• Most basic development environment
• Developer #1 commits code and goes to Bahamas
• There’s no control on what is in the repository
• In this scenario the repository works more like a backup system
• This is where we need a build server
--------------------------------
The most basic of development environment is the one with two developers
commiting code to their source repository. Here we do have the first problem we
presented that Developer #1 could commit his source code for today and then go to
Bahamas. There is no control here that his commit is a complete working commit.
This is when we need to introduce a build server.
6

7. Slide 7
What is a build server
Virtual person, continuously making sure that the source is ok
Most importan task: Making sure source builds straight off rep.
Ensures the developers can start working and contributing to the code at any time
Simple verification – great value
When something goes wrong – server sends emails to responsible person
Implementing is quite simple 1-2 days setting up from scratch
Free tools to use
------------------------
For those of you who doesn't know what a build server is, you might think of it as a
virtual person whose job it is to continuously make sure that the project is doing ok.
The most important task of the build server is making sure the project builds straight
of the repository – This will ensure that any developer can at any time check out the
source code and start working on it. This simple verification can save you a lot of
trouble.
Implementing a build server is a quite simple task, there are free, open source
projects that contain all the type of functionality we've talked about. Setting up a
build server from scratch is typically done in 1-2 days. Once you have a build server
up and running, adding new projects to the server is done very quickly.
7

8. Slide 8
Dashboard from build server
Developers and project managers get good overview of how all the projects are
doing
8

9. Slide 9
That was a brief introduction to build server, now lets talk about testing
• Complexity is the greatest threat to quality
• Change
• No system design, or design has been thrown aside
• Complexity can be fought, fought with design – unit testing
-----------------------------------
I talk a lot about complexity and the evil of complexity. That is because complexity in
software development is largest threat to quality.
• Complexity will grow in any system that is a subject of change
• Complexity will appear when there is no system design (or the system design has
been thrown aside)
• Complexity comes from complex problems (rarely, because you put great matters
into designing a solution for these problems)
This complexity can be fought. It can be fought with design, and the easiest way to
get developers to design their code is through unit testing.
9

10. Slide 10
This is an example of a unit testing framework
Design - testability
Agility
Verification
Unit test – Writing examples
Testing assumes something is wrong with the code and needs fixing
Examples will drive design
-----------------------------------
Unit testing, is testing the unit. And the unit is the smallest part of a system. Writing a unit
test is like writing an example of how you should use this code, and how it should work. I
think unit test is a bad word. It makes you think about testing, and I think it is more about
writing examples for your code.
If I would say, let’s write some examples for this code, it sounds much more positive. Writing
tests, assumes in some way that there is something wrong with the code.
Writing tests for your code will force your code to become testable. And testable code
equals code with good design, because it is impossible to test code with bad design. It will
introduce agility in your code base, because you’ll have an easier time changing things when
you have a suite of unit tests backing you up. After your change, you may run your tests and
make sure that nothing unexpected broke.
The last, (and least important) is the verification of code. You can run your test suite and
make sure that it works. If you move your code to another environment you can make sure
that these units still operate as they should(, and by that way finding environment specific
variables that should be put in configuration files.)
10

11. Slide 11
• How does unit testing fit into a build server?
• Commits
• Unit tests
--------------------------
How does this fit into the build server?
• At the moment we only use the build server to check that all commits are
complete.
• We can also use the build server to run the unit tests. This will give us several
advantages. Our ”tests” will always be run on every commit to make sure that the
code is ok. And running the unit tests on another environment will also take us
further away from the ”works on my machine”-syndrome.
11

12. Slide 12
Integration one of the hardest parts in development process
Posponing causes problems
Build server helps you perform integration more often – detect and fix errors while
there is still time
Manual integration – Automatic and continuous integration
Continuous integration – Immidiate customer feedback
------------------------
Integration (or release) of a project is one of the most difficult moments in the whole
software development process and we've seen how postponing integration to the
very end of a project causes problems. A build server can help you release your
software more often, so that problems reveal themselves early on in the process,
when there's still time to fix them.
While the build server can help you perform manual releases of your software, it can
also perform the integration completely automatic as often as you want, eg. once
every night.
This process makes it possible for customers to always be able to access the latest
version of the site and provide direct feedback of the site, detecting possible
problems as early as possible.
12

13. Slide 13
• How can we enhance the build process even more?
• Unit tests will make sure that old functionality keeps on working, and that is a kind
of regression testing
• We want regression testing the UI
• Browser, clicks around
----------------------------------------------------
We still have the problem with old functionality breaking down while we add new
one. The end user doesn’t really care about unit testing, build servers and what’not.
They just want it to work. Regression testing is a kind of test that makes sure that old
functionality keeps on working while we add new one.
What we want here is regression testing in the UI. We want to control the web
browser and make sure that all of the functionality work at it should and we want to
keep on to verify that old functionality keeps on working as we add new. // Skriv om!
13

14. Slide 14
• We still have the user problem that has to test all existing functionality as we add
new functionality
• This can be automated
• Focus on new functionality
-------------------------------------
By automated ui testing, we can let the tester focus on new functionality and verify
old functionality with automatic tests. And it looks cool to, when you run a test suite
that will open up a browser and click through all the flows.
The tester in this case, would most probably be the product owner in a agile project.
// Utveckla vem som kan vara testare
14

15. Slide 15
We’ve talked about theory – Lets look at a real world example
Screenshot from Google Chrome’s build system
Detailed information on performance tests for every build
Immidiate feedback to developer what performance implicationchanges has.
------------------
This is a screenshot of a part of Google Chromes build system. The image shows the
results of performance tests for different builds. Such system provides immediate
feedback to the developers what kind of performance impact their changes has on
the Chrome browser.
15

16. Slide 16
• Looked at tools to enhance development process
• Solves a lot of common problems
• To sum it up, tools will help you test early – fail fast
• Don’t believe old myths that continuous integration is too complex or expensive,
there are tools that makes this easy and inexpensive to implement
16

17. Slide 17
Thank you and questions from #kiaraepidays
backchannel
17