Merken

Practical Unit Testing in Django

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and the and the man
over and the way the null
and the here's coming can or in a back
here are so today we're gonna look at practically unit testing being getting but if you went to a the testing talk yesterday we get a dominant rewarding tile specifically that unit testing rather than not general gender testing this if you or if you have not done looking before a good intro talkies uh from GenGO con newest 25th then while unit testing doesn't have the so hard that way now my introduction to submit to mocking happened then and then using an agenda context and fewer if you were to use light up there and wish to develop some techniques so that's definitely a good talk to check it out if your new to Tunisia to and so will be covering is recovering unit test we're gonna look at some examples of testing we use forms fields and symptoms like tags were not covering integration testing so I'm not going into the i whether you should use or not use uh marks when it comes to those things that much apart from saying a personal opinion I never use marks and integration tests I can avoid it anyway but they are essential when it comes to you notice the so why United's through I started my gender adventure by doing the tutorial the tutorial into it has aimed I section on testing that section on testing using regression testing now the problem is as a project grows in started it becomes very hard to be a high level code coverage using the gender test client with the card that you're trying to test might be 20 method calls down the tree and so that doesn't really work in terms of really exploring out B cause that you pricing and testing of a teaching modules so we need we need a more direct way of attacking what we're trying to taste rather than trying to test the whole step what it in a project you would do that integration testing so those tests is still there but they knew users as a percentage of tests that integration and functionalities but a whole lot tests going to be unit tests this many dependencies that can exist in a project the methods I can often be more than just take what the other parameters that come in the result comes out the sort of fix there is this classes there's attributes classes you might be changing as intrinsic classes inside those things a side effects and 90 and by increasing complexity all testing and so we need a widening society about all this because that yeah and sometimes really could be so complicated complicated and just not being plausible try managers at such a high level the yeah so what he is I unit test the idea is to place 1 method on the test and your testing the internal operation of that method your testing Herakles other methods and you're looking at what it does when it gives the results of other methods back and what he might do that which might be simpler just returning onwards the neighbors and and everything else here is reliable the side of the ones that was talking so can you tell me that of interaction here what is that animal that we see on the screen not receiving a strand alone on at and output studies they the touch anything I can answer but the point is but it doesn't really matter what is what is the big picture of what you're testing you at testing a method so I we but the nodes a dark little toy . com this loss it doesn't matter the thing is aligned you just testing that naruby the knowledge that written laws and so long as that does you need to do enough to make it work in the context of your method everything else that it does doesn't really matter and also that is indeed tells as we go along but to get you thinking if your testing since some code that takes an already result and your side adding some into it yet you don't need the R. and to test your what you are doing Yoram itself is at the sky of your particular method and we'll have we'll have a look at some examples the point is if your testing just about red recognize that's all that matters everything else is irrelevant so our efforts have to demand everywhere talk about these testing class-based units that we're using functional views are not only using more sign and focused on costless a cost use there's a big car lots of methods in it what they typically
happens is you might be you might be i inheriting from you out there in any might be defining a few methods that add to that just do a few things extra maybe just 1 line of code extra what you're testing is that 1 line of code and the call to the super function and the result comes back and that's all you registered in adjusting anything else to what we can so is this slide talks about each charter right you might is going to be a method that you that your your reader deriving from the class and writing a specific override or perhaps you've noticed you've done that a few times and so announced on mixing and event we're going to allow the phonics in that does 1 or 2 beings in 1 or 2 methods and we wanted to test that so what we wanna do is want test those methods the now what we what what we don't wanna do is we don't wanna call the Django to scorn because of the regression test that relies on the halted you brood being and we don't really want them so what we do is we need to basically true another I have being there me so we can call the function we actually want taste inside the top function there is a function that just represent a little bit from the as the function itself from the gender class as you are lucky to set up at test object like view of or should say summary he sets up there can be a request not anywhere in the and returns the view if you look at as you in the gender source code you'll notice that what exists it does a few other things that are not really needed for a unit test and then to actually test this thing In a set up function the test class we see that we got the Request factory that was the the distance the request factors talked about it's not we in this case we're testing get different but that could be there could be other quantitative commitments it doesn't matter what your own you give it you don't need to worry that you are a resolving you can call it either so your eyes it's really irrelevant just at some strength that we cranked out you which is the view on the test and we call that method that's off the top and that sets up of you and then what we can do is we can directly call the method software if out method that if you have a class on a test is good sigh dispatch method relies then we can just directly called by going you don't dispatch I with the request any arguments carried out we can directly collect method with any 2 or battle all in the US at those that if we have a common functions to riders get context of you just call it directly with idea with a dictionary to keyword and then you look at the new look aware dust inside the so I moving on to forms so we want to test the idea to test the reaction of a method to get some kind of assurance of his card is going to do with the user and the user a function we want to hear so it's got size the claimed method will fall and what it does is its testing 2 nights and the end I use after the start that we use when making the signs that is why we want to make the start something the index so the start let's start so it doesn't do that or not and if there is an exception there 9 we want that not what device media the so he are 2 texts that do that so we have what they do the 1st thing is that patch they claim that the that's and that's inherited by the super call is going to call the perform claim that the which you don't want to call the they form cling effect because we are interested in testing what that does we just want we we so we need a patch that and so you aspect means it'll test whether recalling in the wide and we expect and then we give it a result where it is going to give it a result by basing our goal of what everyone and so on the method but the 1st line is it creates the full form equal so peaceful then it's it's some claimed that now when you're doing integration test that's already done somewhere else but when you when we discuss recalling claims a claim that it doesn't exist so we need to make that that's a dependency so you will need to set it up and put some kind of ordering in the first one there is no indicts so that would throw an exception and we're testing for only a start that it's says resulting goes from quite close the claim that the correct but they looks at what comes out the 1st decision is didn't call the 2nd method did that claim method of the form get called and and it was a which is what we expect the previous method is what 1 called a
super when if we knight coding error call plots for the assertion files then the next line is it says they claimed that has undergone a stop died in there's not indicted appear because because not supposed to do that and now if I if I wanted to positive I want to throw the exception not I could use an assertion called about city rises then put the exception there and then the test will pass if an exception is thrown that's not captured out so I can where I need to throw the exceptional not I can test specifically for that and the final thing is this last session the session is is the result i research the we got back never because it's types result
is the result from super is put into a variable called result and then down the bottom return result finally that bottom line out forget to return a result that final solution will file yeah so and testing it's my method that takes the result of the super cold and will pass them out to the caller I want test that that's something that monitored during so anything that my methods doing I wanted to that and that's what that sessions certain result I basically the needs to testify change the return value back on the patch of lawn 2 D the and then last session will file on this side it's for the yeah is that's not that the concept of detailed unit testing that so going on this is talking about this set animal more conceptual level so I methods do things idea and we trying capture each thing that it does so some of direct in method action such as assignments so doing some some mathematics or whatever and the other thing that I typically do is call stuff and most often but not always that's a called super but sometimes it's a cultural trying things whatever calls you a test that it's calling it as you expect to call it given the inputs that your fading to this function if you say if you only sometimes call so based on certain inputs then you want to price that test for the demise of inputs that should call about and then for the ones that shouldn't call super you'll be looking at its called can is 0 yep the now procedure introduced an if statement you gotta have branch and so that's likely to mean more than 1 test I so you can test data French at the if you're getting too many of them and you get a hold all test prices that's a prime indication that you need to break the thing up just a few notes on the In that apart from what library has this thing call logs and call lots lease side side you vary but let's with cheese of the 1st that Unix element contains all the positional arguments is not just stop that you put in stop arms that anything it's called as a positional arguments the 2nd index is so anything that encodes a paradox I get the thing is a method that's on an object self will be the 1st positional arguments but if it is a class method class is not hot as a positional accuracy than you put in your car a the response and worry knows the name of class class is actually not passed as the 1st position of the word up so 1st position alive even now you actually physically wrought Celia so we recall that in the car and a static method we expect enough that you that study callouts list is used when your calling the function more than once no as you to to make assertions on the parameters for each call so the next thing is certain mixing so we discussed the mixing the will be before and some few other mixing and you you be wanting to test and its methods earns Castlegard a validation object which is designed also it's it's a mixing inside it's designed to work with other without a stuff I enzyme has an init method that doesn't stop tests that not unit serve about mixing which is not in and out of isolating use simple test customize the these fossils so we created a dummy field that I inherits from the test classes the deposits on the test + chapter that you doesn't do it that class doesn't do anything else that's one of past this and when we correct this field we're gonna be calling init method but we don't wanna call the init method of chart feel because I don't care what goes on inside that I'm not testing gender I'm testing my so I don't want to it like I just I need to patch that the and so where the top there where the survey of mixing bond that's the thing on it which the patch object wonder where in order to and not where it's defined where it's important the init method spectacles strain it doesn't return anything sudden infant and so in the test are corrected test field you could say I'm using non keyword odds that those style I'm passing in whatever it doesn't matter what under sparse in some dictionary but this and admit is supposed to pass that all this test cases is testing we are providing non setting so the to the actual mixing but the mixing is used in the context of words mixed in with something else will never use it a lot and so 1 of the assertions which is the bottom 1 test to see whether the new and method of the of the yen buys class was called With that 11 and 12 dictionary let's look at the bottom line do so I'm actually saying on testing the super call in new benefit if it doesn't pass along the and my assertion files so I just a few commons event logs by default when you when try mark evidence from soc your testing and it's not the unit to delete which is under the the so in this the this test case that here we see on line 3 for that their what 1 but they'll 3 more that this is testing something that what is a mixing that could be used without a model form but it could be used in an ordinary for and modern forms of got a segmented and on reforms stock well what happens on a test it was something that hasn't been something that doesn't and is again a where where is it going to throw an exception and so the sound this are test method tests for all of us on it's setting up of you that's got some forms of crowdsourcing saying dictionary of forms form 1 form of and the turns then passes that to the form balance Our method of the thing in some detail if another not to use up the top you see this 3 actions it's patching the get success neural because that's what of about if you if you call for about valid calls the get success euro answer but I wanted to do that I want to go through the class by you are I just want you to know to do what I and I need to think that I I don't want to redirect I don't it's calling the it's it's doing the society civil forms it's doing a transaction is that transaction actually and assertion that tests for that is the for about on bottom well 1 a quick check when it comes to these patches when there's more than 1 of them your order unique it's like a mirror image of the closest 1 in is the 1st that the TI patch then the next 1 up use the high job opportunity to do them in their order not the top patch is the 1st oppositional argument of itself he didn't like it in mirror images that this was off and think about the so again long time so I just they are quick but a quick look at that implied unit testing so I use a dictionary object that but the bias test just does what gender does but it also does indirect so I tested to see whether it can do those things or not and so I need to do is to set up a template with the minimal string that just like the test tags and then actually about the tag set up a context 1 which is what that are in the function does that's the resulting rendered and then I can assert that rendered the tag is doing what it's supposed to be doing right so in summary a unit
test is focused on i specific and that's it out whatever that methods doing directly or what it's calling I have when I say what it what it's calling only have calls and what comes back not what's going on inside it's effectively a black box and if of you classes you sit up the instance with sort dummy function and you have the foundations of that randomly it'll all look to trumpet the slides up but the between and all this sort of got a can increase somewhere on and so on so you're testing on argument statistical engine and you've done in classes subclasses to takes to test
mixing Marx but you can have at that have attributes then between get too much time ago intense I need to delayed attributes and methods where you need to test for the absence faster got any questions and a do you fall into the what's the getting in particularly the last example where you're sort of mocking things and of getting into a little bit of the semantics of how the underlying layers work do you find that tests the the semantics change between versions of Django or versions of Python it another church has a very detailed very specific and and you find that there's an additional maintenance burdens by getting into that much detail that you that you're doing I mean that's a super nice but who about maintenance for that it does exist but it's minimal and the advantage of testings wide is that it pays off at so many times what typically happens as your auto these unit test is your there's a lot of assurance on the underlying causes when you come to do an integration test you might find a few bits that think what life but once fixed-price mentions everything just seems to work of going from 1 version to to the other the problems that can arise from an of we actually go change the code under taste not the testing because because the testing code mocking and all this other stuff the which all code is expecting gender were considered he and that's all your testing so the problems are really winegrower arise I with your tested code not good taste college and you want your test a file in that situation so I have a question about them how do you go about deciding if an integration test would be better for particular of you know where the the and you know doing a unit test for each little block of code because it seems like the within the integration test you can easily requests do the request and then make sure you get back what your warning of but with the unit test here examples and when water set up in terms of marking the things you don't want and you have to decide what you don't want to know about type and how well they have that inside but I integration test user stories including the alternative prices from has text so I wanna see that those stories and captured in integration tests and then the unit has focused on the details of the function so I I don't do a trade off there actually do bother and it improves the integrity of the cause I once you get used to these marks and on the objects you get used to pump new metric quickly like at the ah when you have complicated queries manage where it's sitting up which is you just look at you from I integration testing meets fixtures and the integration test to see if your query makes sense or not and then your unit tests can deal with all the little cases where the pretty much impossible to as fixtures so in the end it ends up working quite quickly thank you again way in a few if
things so if
Resultante
Einfügungsdämpfung
Punkt
Komponententest
Desintegration <Mathematik>
NP-hartes Problem
Komplex <Algebra>
Gesetz <Physik>
Computeranimation
Übergang
Eins
Netzwerktopologie
Komponente <Software>
Middleware
Client
Umwandlungsenthalpie
Einheit <Mathematik>
Datenmanagement
Vorzeichen <Mathematik>
Statistischer Test
Code
Lineare Regression
Punkt
Metropolitan area network
Funktion <Mathematik>
Signifikanztest
Nichtlinearer Operator
Parametersystem
Lineares Funktional
Physikalischer Effekt
Güte der Anpassung
Äußere Differentialform
Übergang
Kontextbezogenes System
Datenfeld
Funktion <Mathematik>
Geschlecht <Mathematik>
Einheit <Mathematik>
Client
Projektive Ebene
Garbentheorie
Maschinenschreiben
Gruppenoperation
Soundverarbeitung
Interaktives Fernsehen
Term
Code
Abenteuerspiel
Signifikanztest
Äußere Differentialform
Knotenmenge
COM
Gruppoid
Touchscreen
Beobachtungsstudie
Überlagerung <Mathematik>
Quick-Sort
Chipkarte
Integral
Körper <Physik>
Parkettierung
Modelltheorie
Resultante
Bit
Komponententest
Hinterlegungsverfahren <Kryptologie>
Computeranimation
Umwandlungsenthalpie
Statistischer Test
Vorzeichen <Mathematik>
Lineare Regression
Code
Mixed Reality
Punkt
Gerade
Funktion <Mathematik>
Signifikanztest
Lineares Funktional
Parametersystem
Fuzzy-Logik
Kategorie <Mathematik>
Systemaufruf
Ausnahmebehandlung
Quellcode
Kontextbezogenes System
Instantiierung
Gleichheitszeichen
Teilbarkeit
Ereignishorizont
Entscheidungstheorie
Gruppenoperation
Rechenschieber
Funktion <Mathematik>
Geschlecht <Mathematik>
Rechter Winkel
Automatische Indexierung
Einheit <Mathematik>
Subtraktion
Ausnahmebehandlung
Gruppenoperation
Code
Signifikanztest
Äußere Differentialform
Software
Abstand
Integral
Chipkarte
Endogene Variable
Objekt <Kategorie>
Patch <Software>
Hypermedia
Faktor <Algebra>
Resultante
Komponententest
Element <Mathematik>
Baumechanik
Sondierung
Login
Template
Computeranimation
Eins
Übergang
Einheit <Mathematik>
Statistischer Test
Prozess <Informatik>
Code
Minimum
Konditionszahl
Mixed Reality
Default
Gerade
Signifikanztest
Lineares Funktional
Parametersystem
Befehl <Informatik>
Schlüsselverwaltung
Fuzzy-Logik
Template
Systemaufruf
Ausnahmebehandlung
Plot <Graphische Darstellung>
Digitalfilter
Schwach besetzte Matrix
Kontextbezogenes System
Ein-Ausgabe
Gleichheitszeichen
Codierung
Algorithmische Programmiersprache
Gruppenoperation
Motion Capturing
Differentialform
Transaktionsverwaltung
Datenfeld
Suite <Programmpaket>
Menge
Einheit <Mathematik>
Automatische Indexierung
System-on-Chip
Geschlecht <Mathematik>
Ablaufverfolgung
Ordnung <Mathematik>
Message-Passing
Fehlermeldung
Zeichenkette
Objekt <Kategorie>
Ausnahmebehandlung
Gruppenoperation
Signifikanztest
Äußere Differentialform
Informationsmodellierung
Task
Datentyp
Programmbibliothek
Vererbungshierarchie
Data Dictionary
Indexberechnung
Transaktionsverwaltung
Bildgebendes Verfahren
Beobachtungsstudie
Mathematik
Default
Linienelement
Eindeutigkeit
Verzweigendes Programm
Validität
Mailing-Liste
Objekt <Kategorie>
Summengleichung
Patch <Software>
Paradoxon
Komplex <Algebra>
Parametersystem
Wort <Informatik>
Brennen <Datenverarbeitung>
Objekt <Kategorie>
Bit
Komponententest
Wasserdampftafel
Versionsverwaltung
Term
Code
Formale Semantik
Einheit <Mathematik>
Statistischer Test
Ganze Abschließung
Datentyp
Äußere Algebra eines Moduls
Vorlesung/Konferenz
Attributierte Grammatik
Umwandlungsenthalpie
Signifikanztest
Videospiel
Addition
Lineares Funktional
Parametersystem
Statistik
Kohäsion
Physikalischer Effekt
Vererbungshierarchie
Güte der Anpassung
Systemaufruf
Abfrage
p-Block
Instantiierung
Elektronische Publikation
Quick-Sort
Integral
Softwarewartung
Objekt <Kategorie>
Einheit <Mathematik>
Geschlecht <Mathematik>
Instantiierung
Vorlesung/Konferenz

Metadaten

Formale Metadaten

Titel Practical Unit Testing in Django
Untertitel Mocking and Testing Techniques
Serientitel DjangoCon US 2017
Teil 39
Anzahl der Teile 48
Autor Merry, Wayne
Mitwirkende Confreaks, LLC
Lizenz CC-Namensnennung - 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/33204
Herausgeber DjangoCon US
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract This talk is an opportunity for you to explore practical ways of improving the test code you write. Unit testing can be challenging, but with the right toolbox of techniques, it is much easier to write unit tests that not only enable high degrees of code coverage, but assurance on each action of your code. Django provides an excellent test environment that facilitates testing across the whole of a project, however Django’s documentation and many online examples focus on integration tests. Any typical use of the Django test client is an integration test. Tools such as selenium also provide a frame work for usability tests, functional tests or integration tests. What is missing in this is a close look at unit tests. It is difficult to obtain high code coverage with integration tests alone. This talk will build on Daniel Davis’ DjangoCon2015 talk “Why Unit Testing Doesn’t Have To Be So Hard”. That talk introduced the concept of using mocking to deal with the complexity of unit testing and gave a number of simple examples. In this talk, we will apply mocking, dummy objects and harnesses to unit test in the Django environment. We will focus first on class based views. Django provides an extensive Generic Class Base View hierarchy of base classes and mixins. These define a series of methods that focus on various elements of the response process. For more complex applications, this system provides much of what is needed but often customizations are needed and these can take the form of subclasses overriding one or more methods, or perhaps mixins that are built to implement abstractions of these customizations. In order to unit test these customizations, we want to place each individual method under test. To obtain strong assurance of code performance, we want to place under test each action of the code, plus its coupling with its base class(es). A test harness, mocks and dummy objects all assist in this process and we will explore examples of such. Mocks particularly facilitate our tests by us being able assert on what is passed on other method calls and on the super() call. Mixins are used to implement customization abstractions. Their methods can be unit tested making use of dummy subclasses. Form classes also benefit from unit testing. Form classes may define clean methods for validation, and these clean methods can be called directly in unit tests for both valid and invalid data. Some modelform classes may implement business logic in their save() methods and these also highly benefit from unit testing. Both forms and views often make use of the ORM. When performing integration testing, this often means setting up test fixtures, but for unit testing it might be much more efficient to mock out ORM calls such as filter(), all(), count(), etc. Sometimes code under test will chain these ORM functions and this also can be mocked. We will then consider a more complex example of a view that makes use of an inlineformset. inlineformsets are more complex form objects, but various approaches can be used to unit test views that make use of formsets (along with unit tests of the formset itself). We will close with some template unit testing. The content of this talk is built on examples taken from real systems implementation. These should give many Django practitioners a boost in their day to day testing toolkit.

Ähnliche Filme

Loading...