Merken

TDD is not about tests!

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
as the driven test important that's what actually changes when you actually do it like that so it's a self the development process that is based isn't on a very very short cycles that you would be very often start by writing test and then you make it right this it fails and the red phase and then you write a minimal amount of code to make best path and then you write the test and the test positive and it's called the green phase and then because you have written the minimum amount of course maybe also radical you want to respond to you can refer to both the code and the that suggests not at the same time because it's not wise and when you start with the it's it's really useful if you take great cosmos so you write a little bit of test score and then a little bit of code to make the test pass the reflected you go back you add another little beat you make that last year fire and so on and so forth and the more you do this the more in your in your brain basically you learn how to work with this with this kind of back and forth between tests and course which there some pointing to be able to take longer and then you go like taking longer steps and you take them really long and some point during trouble and so you go back to short steps you fix whatever you have to and then you try increased a little bit more you get some core of comparable size for you to work with uh aware that we do when we start it starts with the business requirements so that's very important you have to understand the business requirements and then when you're clear from the business climate and you and that you decide to start writing a test to make it faster from text has refined and so on and so forth and until with this is Parliament's there and then you get to the next business requirements from this point on the training was completed but the master's degree and they kept giving the example in the set which is just the mechanics if you know how to use a steering wheel years which accelerator and brake but narrative in a car would you call yourself a pilot of course not and talk to some people call this this and I know all about the generate enough article but have you ever tried it's not it's not really for well if you don't try it do so in
the trial what changes in the brain when but without the you go from the business requirements to the cold and when you think about the code you have to take care of those things what the code is due to do we need to deliver this functionality and how In this that we need to cycle using a loop when you call this function so it's 2 very different things the what and how and take care of both of them at the same time so our brains concentrating on on the other hand when you use to do you basically mostly take care of the what when when you're writing your best because the tests testing what should happen in and then you take care of the house when you're writing the code itself so you have your brain concentrating on each of those that have 2 different times which means it's like it's like having to brain so it's it's much more module you become like much much more powerful local changes in the media immediately and that's some common aspect so what can we do please principle keep it simple stupid which means basically by forcing yourself to have a text that represents something that you couldn't do tend to again for right the minimal amount of code in order to deliver them because basically remains simple you cannot and take care of you super architectural things or all of the code out to automatically states simple which simple you know and then the governing principle on and focusing on understanding the business environment writing a test In the past it's not likely that you're gonna engineer difficult because you don't you don't have the freedom of code that says you I need to do this and then when coding there's nothing said telling you what the code should do just in your mind and then you go at all and I'm also gone and this could make it more immediate which is something that we be given the 3 strikes and the fact that I have taken this of the history and development with items from person 1 is who just right it's a few months ago that basically says um when you fact phase and then you find here what on functionality and basically the same functionality just wait for the 1st of occurrences of something really similar to fuel group these and factor out the mixing or whatever too soon when the ThunderCats parents uh comes out you may realize it's not as easy to make that work with the mixing that you just so you may also have to do a lot of refactoring on the other hand going for 4 or 5 that's not so please try to find is a nice balance which you can do all the architecture design when you part of the course and the beauty of it is that we have test you can refer to with confidence and then do strangulation translation was puzzling for the so let's let's see an example let's say that you're writing a test and just making making sure that your square function that takes place through is producing number 4 if you think about it at this point although we haven't called base case to fulfill that requirement which basically says I just wanna know that your function returns for you can do this you can see this actually suggested by writing the the authors and schools stated do you make right good wanted that called inappropriate because that's not correct so we do the same relation which means we can point to the same function from 2 different angles which would cause us to have to fade into different ways which is compatible at that point we need to write the the the real so the right the actual logic when you have strangulation like that and this is this is very nice but not just not just because it's like a theoretical thing but it's because you get something that you get test that basically is there and then when you triangulate during have tested deals on 1 of the best 1 that the main
benefits are you refactor with confidence because you have a set of tests that when you touch the gold and you change something like in the 1st example where the boundary that was going to be you have tested fails readability because it's much easier to see called was designed with tests best first basically even though or even though it's like a given and you take care of the design part when you're when you're writing your tests because when you're writing something letter writing patient with if you're if your unit testing we have this the unit of gold so you have to think how the structure of the school you can't just right so you have to do thought which means you're thinking twice about called when you test them when you actually right which we systems are much better much more reliable is small groups couples it's easier to test and maintain the easier to test of course because it's coming from the and it's easier to maintain because it's was structure and when you do test 1st you have a better understanding of the business requirement is in order to start writing your there then you have to have a very clear in your mind what is the business requirements that will drive the design of those statistician here not clear you will find yourself blocked at the test level which basically will prompt you to go back and find understand better this distance required and then my testing in small units it will be much easier to and also you will have the perks of having tests as documentation because by having small that's easier to read and just go through it very quickly and so all chemical the this which is sometimes even easier than read in English sentences that describe the functionality of the English can be misleading especially if I right so having a text which is vital that you know what you know it's it's very useful and highest speed it takes less to write tests and cold and right called and then having to divide I have I can tell you this is my personal experience was working for a company called we were competing with other companies to get the best preview you access to the features of the advertisement API and we have to deliver a proof of concept in in about 6 weeks we succeeded it was a monolithic jungle publication and the order of all was not tests didn't have time to to that so not as we do that with the coding we do over time and we're go on on some of this stuff and the last 2 weeks was spent just a few fixed to about that would be drawn to phrases and it was just 1 one's knowledge on the Web site but it's also complicated task in a short amount of time by the size of the people that basically we're going crazy divided because we're changing something here was written something that you will fix it you bring something there and then this the you a that flows through your course on the other hand we have we done that 1st that time that we spend dividing we wouldn't have that we have and the main the main shortcomings of this technique is that the whole company needs to be leaving it otherwise you can fight for the time report she something that's me and some of my colleagues were very well we need to make sure that there is no time to the best then you have the but it would be a problem that we will have a later OK so we got the right to the core and then how it doesn't work so well and so long as you don't want to another you you have to really really convince everybody that he's going to go and this is really hard to see what happens in the long term there are a lot of all we and find myself included most of the time just see what happens tomorrow we need to deliver to model we need to make the client had tomorrow and we tend to forget about the blind issue mislead is read or if you don't understand or if they are incomplete business requirements it means this will reflect in the type of tests that you write and this was also reflected in the cold and without the business requirement by the look of the tests but that they can look at the cold breaks that past with so that code and the tests they would they would share the same lines but the same think that you means from the business requirement so In this case I think in the heart of the spots on variance for example is helps on this because you have to discuss what you're doing which means you bring up a discussion about the business requirements and then you realize you I understand it this way my colleague understand that for a lot of work that you have to ask for plays shows and then this does not and also badly written tests are hard to maintain for example the tests with a lot of moxie they're very hard to maintain because when you change among you're changing an object and this is just a of you can do whatever you want with it and if you're breaking up because it just change mock and you make it do something else and then you make your code part but if that is representing the real object as it should and that object is not is no longer the all then you have parts so when you have marks you have to take extra care in order to refine the test and you could solve the issue of of the energy issue real-life examples because 1 of the things that found told me I was like yeah OK it's all good and nice when it from a theoretical point of view but then you realize what evidence so for example you hi my company you tell them I really want to test they say good they don't they were the 1st and they have a legacy code that is not tested you you have to call that you have to change something probably you read the whole thing to understand how it works and you write tests were and this is wrong because if you called understand how it works and ride transporting what serial version of the site of basically you're going from the cold to the text of 1 and 2 is to go from the business requirement to invest to the cold of the metal approaching this would be a with the cold right reverse-engineer what are the business requirements that were behind that cold and then write tests for concentrating on the water part not on how to do to the the fail actually
tests will concentrate on the war on the out changing the horrible along you say we
have a general view and we need to insert pagination filtering and sorting in you will eventually a bunch of things we get the data that the that from certain source complete and the could be and things could be a million things and we do have a bunch of things and then we went out and played at some point so we need a lot of initial filtering and sorting and it's not possible to do it at European level because it's too complicated and is not tested so something that I did
after discussing it with with my colleagues was less right to is the subject of much needed time insert them into the function into this without changing anything that was happening before we get to the of all after we got the but those 3 functions that's right into the so at least we're changing the course yes but that it of course will be rock this is a very good way to go about it because in the end the function was not caring for about what data was coming from the search so it's not that they're not shared progeny of students in any in any way introducing a new functionality into an existing called which is not best that's a masterpiece of political does a lot of things like the function uncle bold properties so so how do we how do we change because of course you will not have to test their time to go to every the law was to check if that for is is the correct or not so what do you do by 1 possible solution would be to come up with 1 test for the new functionality that you're trying to insert and then changes function which was not tested before it's not just now but that new functionality is that the next time you you go back to this function refer to what happens 1 test you come up with another test and then you go back and at some point you you you will have a bit of tests behind this of which which means I the function was was written and if you just keep of interest or at some point you realize the function as about because you've got his start having tests for when so the fall was
in the center after all of these he went back to the princess and passed the exam getting married and when the minister said you can kiss the bride nothing changed it was
just adopted after all what's the moral of the story the things that the tested the 1st such the thank you very
much the fact the we we appearance of questions do have the uh and also all efforts of all sons were thought it was really enjoy it and level and my question is how do you put your testing directories the
structure because I have something the whole of all kinds about I have trouble to to checking if the cold i think still make already has some so how do you will them so for example when is that the genome project you got tests in the application for the 1st thing that is to remove that and I reproduce the political structure in tests for the preventing the thing with test and the score this is 2 main advantages test basically I find because it if you know that if you know the tree defined it good the same 3 with tests and also when you deploy you just the that that for the because sometimes when you deploy and occasionally someone run the tests on production you get your production at the base of and that's not so I just want use the basically the tree of my life of my probably there's also other approaches this works good out of the way and then for function tests or integration testing you may want to have a separate for as well or maybe even subprime separate repository for example a you're integration tests it's likely that they want to be of uh testing what's just in 1 representative maybe it's more representing more and more services or more efficient don't we have like the whole project dedicated to we have question here somewhere the time in hi as humans we are I believe sometimes there can be mistakes on the test data you abide by post or by hand calculations in your experience how often do those mistakes happen and how do you cope with it they have been more when you you'll have to deliver about yesterday when you have the luxury of living much more they have been less and what you want to do is take a good care of features and especially when you change the tests or you have migrations take taken care of those because basically those are the things that you take that to test against so they need some some laws me for example can't write unit tests somewhat an interface style which means I have some inputs and I check on the other rather than mocking everything I I tend to mark the the least possible because it's dangers and what was the 2nd question I mean in your experience how often for example in the examples you printed before 1 of the members could be wrong by a type 1 you will notice that while you're writing based on the assumption how often does that happen and how these detect the way we that their requests so all we use the french system we have story branches and then we have a staging branching before the master branch there's at least 2 requests for other people other than the guy who wrote the code to take a look at the code and you will read it so most of the times the stuff detected on on the eastern side of these 2 passes that's that's very thank you you the I will especially involved in discussions about the some guys for the ending that if you focus too much on tests using the unweighted test as some of you may leave for all the data from thinking about the architectural the global to the design of the called the how different parts of the close coupling between them are the performances of but we say to them I would say that this is not 1 of a methodology that fix everything and it's almost every problem you still have to take of the architecture of the care of the design and you can do it in front of the what people who do this and find themselves neglecting the rest of the code is because public they believed he can do too much the gives you have a good way of writing the code and a very good solid that days that basically choose you optimal when you're on this subject and refactoring like amount because you've got tests you still have give it your best shot and take care of the could you right but we do you you've got this extra thing extra electric that basically keeps you on the right and on the right path is just something that you have more will not solve all the other things that you have thank to may have 1 last question no more right
Softwaretest
Kraftfahrzeugmechatroniker
Bit
Punkt
Extremwert
Prozess <Physik>
Wellenpaket
Extrempunkt
PASS <Programm>
Paarvergleich
Code
Computeranimation
Gewöhnliche Differentialgleichung
Software
Softwaretest
Minimalgrad
Zustandsdichte
Menge
Schwebung
Dreiecksfreier Graph
Statistische Analyse
Speicherabzug
Softwareentwickler
Phasenumwandlung
Chipkarte
Punkt
Komponententest
Gruppenkeim
Versionsverwaltung
Turing-Test
NP-hartes Problem
Extrempunkt
Computeranimation
Eins
Übergang
Client
Softwaretest
Einheit <Mathematik>
Reverse Engineering
Code
Mixed Reality
Translation <Mathematik>
Kontrollstruktur
Perkolationstheorie
Phasenumwandlung
Gerade
Softwaretest
Lineares Funktional
Extremwert
Sichtenkonzept
Winkel
Stichprobe
Teilbarkeit
Randwert
Menge
Rechter Winkel
Beweistheorie
Reelle Zahl
Ordnung <Mathematik>
Programmierumgebung
Maschinencode
Web Site
Mathematisierung
Zahlenbereich
Mathematische Logik
Term
Physikalische Theorie
Code
Task
Loop
Informationsmodellierung
Bereichsschätzung
Datentyp
Vererbungshierarchie
Abstand
Datenstruktur
Softwareentwickler
Varianz
Autorisierung
Relativitätstheorie
Physikalisches System
Summengleichung
Objekt <Kategorie>
Energiedichte
Quadratzahl
Zustandsdichte
Dreiecksfreier Graph
Mereologie
Hypermedia
Triangulierung
Speicherabzug
Serielle Schnittstelle
Computerarchitektur
Verkehrsinformation
Softwaretest
Metropolitan area network
Softwaretest
Vervollständigung <Mathematik>
Punkt
Sichtenkonzept
Code
Computeranimation
Übergang
Softwaretest
Lineares Funktional
Bit
Punkt
Abstrakter Syntaxbaum
Kategorie <Mathematik>
Mathematisierung
Stichprobe
t-Test
Digitalfilter
Gesetz <Physik>
Computeranimation
Portscanner
Softwaretest
Zustandsdichte
Code
ATM
Softwaretest
Metropolitan area network
E-Mail
Verzeichnisdienst
Computeranimation
Informationssystem
Übergang
Komponententest
Selbstrepräsentation
Schreiben <Datenverarbeitung>
Kartesische Koordinaten
E-Mail
Gesetz <Physik>
Code
Computeranimation
Netzwerktopologie
Migration <Informatik>
Datentyp
Datenstruktur
Softwaretest
Trennungsaxiom
Videospiel
Lineares Funktional
Dokumentenserver
Güte der Anpassung
Verzweigendes Programm
Physikalisches System
Rechnen
Ein-Ausgabe
Biprodukt
Integral
Dienst <Informatik>
Rechter Winkel
Mereologie
Projektive Ebene
Computerarchitektur

Metadaten

Formale Metadaten

Titel TDD is not about tests!
Serientitel EuroPython 2015
Teil 122
Anzahl der Teile 173
Autor Romano, Fabrizio
Lizenz CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
DOI 10.5446/20110
Herausgeber EuroPython
Erscheinungsjahr 2015
Sprache Englisch
Produktionsort Bilbao, Euskadi, Spain

Technische Metadaten

Dauer 23:42

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Fabrizio Romano - TDD is not about tests! TDD is not about tests! Well, actually, it’s not a about writing tests, or writing them before the code. This talk will show you how to use tests to really drive development by transforming business requirements into tests, and allowing your code to come as their natural consequence. Too often this key aspect is neglected and the result is that tests and code are somehow “disconnected”. The code is not as short and efficient as it could be, and the tests are not as effective. Refactoring is not always easy, and over time all sorts of issues start to come out of the surface. However, we will show that when TDD is done properly, tests and code merge beautifully into an organic whole that fulfills the business requirements, and provides all sorts of advantages: your code is minimal, easy to amend and extend, readable, clean. Your tests will be effective, short and focused, and allow for light-hearted refactoring and excellent coverage. We will provide enough information and examples to spark the curiosity of the novice, and satisfy the need of a deeper insight for the intermediate, and help you immediately benefit from this transformative technique that is still often underestimated and misunderstood.
Schlagwörter EuroPython Conference
EP 2015
EuroPython 2015

Zugehöriges Material

Ähnliche Filme

Loading...