Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
welcome back our next presenter is from the foreign land of Ruby he's a ruby developer by trade he's working at source labs as their rub evangelist he gets to help other developers make things he's going to talk to us about web testing for ninjas
please join me in welcoming Dylan Lacey thanks everyone so I have a little disclaimer first up this this is a Python talk everything in it is Python but I will be mentioning Ruby just a little bit so I'm kind of going to flip flop between some some docker
some testing philosophy and some general pro tips so if you are looking for just one of those things maybe you want to just come back and read the slides later but so why am I here why is he rubios coming to talk to you about testing I mean that doesn't
make so much sense right so I I am the developer evangelist of sauce labs which is kind of a roll it's a bit weird we sell a developer product so rather than having suits and marketing people we have developers who helped other developers use our stuff
and so I help people get going I deal with our integration I do our support i do screencasts and sauce labs ourselves are a cloud-based product similar to Heroku but we're Haruka does application platforms we do testing platforms so we have browser OS
vem combinations we have about 150 of them and what we do with those is we give them to our users so they can test things astute people will have noticed that that's the same as the original number of Pokemon so I talked to everybody at work where a Python
shop and I asked them about testing because we do a lot of testing surprisingly enough we do all the browsers we do offer all the operating systems we all do all the versions and all the languages and all the tools and all the frameworks for sufficiently low
values of all and I am interested in developing I'll of developing I love testing and I talked to people at work about different tools and so ruby has a thing for testing we may actually have a testing problem but it's not a problem we can stop anytime
we want we love it and there's this tool in really cool capybara and so I talk to people at work and said hey there's this tool called capybara here's what it does is there a similar tool for Python and I got what seems to be a very pythonic response
which is all there's a whole lot of things that do that okay what do they all like I don't know I've never used them so I investigate a 1 which is splinter splinter is also a giant rat a capybara is this huge kind of hamster fingers ridiculously
big and splinter of course is the giant rat from Teenage Mutant Ninja Turtles now splinter is awesome splinter is a DSL for doing acceptance tests in browsers so it can sit on top of a whole bunch of different browser automation tools and run through a browser
in a language that reads better than most of the internal tools languages do it's relatively tool agnostic it doesn't have a huge number of things that supports but it supports some integrations that are fundamentally different so what you can do is
you can switch platforms underneath splinter without changing any of your tests you change your conflict or that's all you need to do it doesn't support everything obviously but you could probably write adapters for most of your favorite tools if they
don't already exist it currently works with chrome firefox phantom j/s zope test browser and selenium remote browsers selenium is a fairly common browser automation tool that supports most of the major browsers zouk test is soak test phantom j/s is a headless
WebKit javascript-based automation framework so you can run your browser and get a DOM and JavaScript engine without having to actually take up a monitor somewhere so when I tell people about this sometimes I get funny looks because I said it's an abstraction
because it is people have problems with abstractions that people think instructions are evil because the concept of an abstraction comes paired with the concept of a leaky abstraction which is an abstraction that has a bit that's missing that either causes
you problems or doesn't work properly or gets bigger over time and this is true this is a very real problem with abstractions but a lot of abstractions don't actually have this problem if they're leaky and you know where the leaks are it doesn't
matter as long as you can avoid them if they're not leaky it doesn't matter at all and the reason the distractions shouldn't scare you whenever you encounter them is because all our programming languages are abstractions python is an abstraction
of C which is an abstraction of machine code which is an extraction of no weight at a section of assembler which is an abstraction of machine code which is an abstraction of bits everything we do is built on abstractions don't fear them so acceptance testing
is about running your tests like a user does unit testing you take a module or a method and you just make sure it works properly integration tests you make sure the bits of your framework crammed together and work properly acceptance tests should always run
like a user does because if they don't you can't really guarantee that what you're doing is acceptable there there the bit that takes what the user said to you they want and make sure that that's what they're getting coding is fun i love
coding i assume most of you do if you don't are you here but ultimately it's a side effect what you're doing when you're coding is you're trying to make sure your user is happy if your user is happy it's great that you managed to code
but you didn't give them what they wanted you haven't achieved your goal you've just had a bit of fun in your editor so acceptance testing is really important I set up there it's just as important I don't think unit testing is anywhere
near as important as acceptance testing acceptance testing is the most valuable thing you can do to make sure you deliver software that delights your users and it's where we don't put our effort we don't start at acceptance testing it's usually
[ ... ]
Nota: se han omitido las otras 3.084 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.