We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

BDD: You’re doing it wrong!

00:00

Formal Metadata

Title
BDD: You’re doing it wrong!
Title of Series
Part Number
55
Number of Parts
173
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Production PlaceBilbao, Euskadi, Spain

Content Metadata

Subject Area
Genre
Abstract
Rafał Nowicki - BDD: You’re doing it wrong! Talk about mistakes we made and best practises we have elaborated while implementation Behave Driven Development into one of the projects. Great idea to coverage whole application with functional tests fall down in development chaos and reborn on new better foundations. Project referred is web-based big data management which main features are transcoding and file sharing. Thanks to Django and many Python frameworks we have web interface for it and we are able to run automation tests with Selenium.
Keywords
51
68
Thumbnail
39:40
108
Thumbnail
29:48
Software developerSoftwareWeightStudent's t-testInteractive televisionMultiplication signProjective planeSoftware testingStudent's t-testSpeech synthesisSocial classNumbering schemeData miningStatement (computer science)Ultimatum gameComputer iconLecture/Conference
World Wide Web ConsortiumData managementSoftware testingImplementationSoftware developerLoginWeb pageMetropolitan area networkBinary fileExecutive information systemIntegrated development environmentUser interfaceContent (media)Speech synthesisProgrammer (hardware)Sign (mathematics)Projective planeService (economics)Web 2.0Video gameSoftware developerForm (programming)Computer programmingFormal languageRight angleImplementationMereologyWeb-DesignerExterior algebraWeb pageRoboticsSimplex algorithmProduct (business)Data managementWeb applicationView (database)Functional (mathematics)Software testingPoint (geometry)Integrated development environmentComputing platformUser interfaceCodeDifferent (Kate Ryan album)Mobile appException handlingContext awarenessComplex (psychology)Login
FingerprintIntegrated development environmentDensity of statesStandard deviationImplementationMultiplication signPulse (signal processing)Software testingVirtual machineTheory of relativityCodeSign (mathematics)Computer architectureFunctional (mathematics)MathematicsOcean currentStreaming mediaRepository (publishing)Revision controlNeuroinformatikScripting language1 (number)Message passingWeb browserValidity (statistics)Computer animation
Integrated development environmentStandard deviationDensity of statesWeb browserMereologySlide ruleSoftware testingWhiteboardCodePoint (geometry)Integrated development environmentComputer architectureTask (computing)Projective planeVirtual machineView (database)CASE <Informatik>Computer animation
CASE <Informatik>TelecommunicationSoftwareSoftware developerDifferent (Kate Ryan album)Slide ruleMereologyFlow separationSoftware testingComputer animation
Roundness (object)Lecture/Conference
Transcript: English(auto-generated)
As Jurgi said, my name is Raffo Nowitzki. I'm one of the superheroes, which works on STX Next, and I'm also still student of Wrocław University of Technology.
I'm really glad to be here. It's my first EuroPython, and it's also first time when I have a speech. So today we are going to talk about automated tests, but this talk won't be
so technical as many I saw here. I'm going to share my experience with a project where we was implementing the automated tests.
So there is agenda. At the beginning, I will give you a background about the project I used to work on, just to keep the context much better.
Then a short talk about test automation in web development, and I will shortly show how we do it in Python. Then we jump to behavior-driven development.
I talk about benefits, problems, solutions, and then I'll show you the conclusions. So a couple months ago, I used to work for a project which was an interface for assets management platform,
web interface. So we had the chance to implement a Selenium test for it to test it more efficient.
We work in small Scrum teams, and I will show you my point of view as a developer. So let's begin from test automation in web applications.
Two things which we need to write automated tests is scenario, most scenarios are automated tests. They are written in Gherkin language,
and we also need the programming part, which is Selenium API, and it's what we use it over here. How it's looking at Python?
So we've got an example scenario, and this is the Gherkin syntax. You've got the name of the feature, name of the scenario, and you've got the steps which is separated by keywords
which is given, when, and then. And then we make implementation of all of any steps in this scenario. So for example, when we had the given,
and it has been written that I'm on the login page, we have the Python method where we can program the behavior of the web robot, which is Selenium.
Here you can see there is, actually you can put the Selenium code over here, but to keep it clear, it's much better to make adapters.
It will help you to not duplicate your code in the future. Here we are, behavior-driven development. But I'd like to start about test-driven development. How many of you knows or heard about TDD?
And about BDD? Okay. So generally, to be sure that we are on the same page, behavior development comes from TDD, but it's mostly focused on functionality
and on business values. Yeah. So, a few days ago, I met some guy over here,
and I told him about the contest of my speech, and to be sure that he knows what's the BDD,
I asked him to collapse it, and he said business-driven development, and then I realized it could be, it's actually like this.
So, about BDD, we've got benefits, but we also had a lot of problems, so I'm going to show you the benefits problems and then the solution of those problems, which we got.
So, improved developer skills. Because it is the way of programming when you have to write the test at the beginning, it's quite a challenge, especially for beginners
or for programmers who work on a more complex project or on new part of the project, which never touched. It's also, the big benefit is that the developer learns
about the business values and about the end user's needs, and here we have cooperation between developers,
QAs, and business people. So, I think it's really hard to meet a developer who are experienced in both, I mean,
he's a great programmer, and he understands the business values of the project, of the task, which he do. Here we have end-to-end tests focused on functionality, so we are going to help our QAs, our testers,
to run the automated test, except on manually boring stuff and the biggest benefit, I think, in way of you have all app covered by functional tests,
you can make a completely new app, which fits to those business needs,
and you can create completely new user interface, create a project for different platform, and run the test, and check if it still covers
the main values. During the implementation of the Selenium tests, we had a lot of troubles, and to begin from inexperienced people,
we have, there was around four teams, which was working on implementation automated tests, and I really knew all the people from at least two teams
and all of them are good programmer, but all of them, any of them have never need to write something with Selenium API.
Another one was different environments, and it sometimes happens when you write the tests and you run it on your computer, it pass, and then someone pull your changes,
and he's running this test, and it fails. We recognize that there are problems with the browser versions, Selenium versions,
and WebDriver versions. We didn't have automated validation of our builds, so the way of creating the,
to keep the code in one repository, was that we get the plus ones for a code from our coworkers on the PR,
and before merge, someone else had to run this test on his machine, check it if it pass, and then give another plus one that the test passes. The teams which duplicate their code,
their work. It happened many time when we, when we was working on implementation the test for new features and for current functionalities,
we didn't have, we didn't cooperate as well, so it was also the problem,
and there was even one team which was working on a new feature on isolation, and it was actually my team, so when the idea of the cover, the app, with the automated test came,
my team was focused on delivering a new big feature, and we used to work on our feature branch, and we used to do the same with the Selenium tests,
but it was a bad idea because after few weeks we recognized that the master on test code base was completely different than we have the changes
on our branch, and it is also about the premature architecture because the architecture wasn't so, we didn't have the completed architecture
from the beginning, we just get some idea, how to do it, and then we was improving this recursively
as we do it in a scrum. Okay, so what was the solutions? So for inexperienced staff, we went after a few days,
actually the solutions sometimes happens after a few days, but sometimes has been resolved after a few sprints, so from the beginning we started to run the workshops,
and we share our knowledge with the other teams, we created unified environments, and it was in two steps I think,
because one of the thing we did, we've made, is to run the script that builds all our environment with all the dependencies,
and another step was that we've got the phantom browser on a virtual machine with all things which we have, which we need to run the tests.
We started to work in transparency, as we should do from the beginning, we get the one board on the JIRA,
where all the tasks about the Selenium code base has been touched, and everyone can check which part of the code base our friends touch, and the architecture has been improved,
we came to this point that we covered all the use cases, and we get one standard,
but we've cleared the documentation for it, and we also started to support the versioning, and the conclusions, so I give you an examples
of the problems which we had in our project, in your project it could be, or some of them can work, but I get, and write down on the slide
to the most important thing for me, and one of them is about communication, it fits to many cases,
because the communication is about the most important part of software development process, and it's about people, I strongly believe that it's much easier and nice to work together on one solution,
rather than work in a separation on different solution for the same problem, and then fight for the best solution which will be our standard, and another thing about the Selenium test mostly,
you have to learn patience to write this test, because in general I really appreciate the work of the QA's of the testers, which have to be so patient
to repeat the same steps over and over again, and writing automation tests, it's like,
it's like this at the beginning, so you really need to be patient people, and I think that's it, I'm looking for questions.
Do we have any questions? Alright, thanks a lot, let's give one more round of applause. Okay, thank you.