 Hello, everyone. I'm Rohan senior developer at Bloomberg working in the company's Pune office So Bloomberg is a technology company working to create the most sophisticated platform for financial professionals We had quartered in New York, but we have offices in Pune and various other locations around the world Do visit us at our booth G7 to find out more about the company This is the slide for that Okay, so we all write unit tests for all the modules we send to production, right? And we always annotate all our code so that we can run syntactic checkers. Of course who doesn't? Well, not really. We have all sent code to production that what I would call is subpar quality-wise Right. So over in our team, we wanted to create a framework that allows you to improve the quality of your code This summer we had Pradyum Gidam interning with our office You may know Pradyum as one of the maintainers of PIP Virtual and and or you may have heard his talk yesterday on packaging He created the first version of puto. So what is puto? Puto is a framework for improving the quality of your code It will it provides a command line interface and a programmatic API to automatically generate unit tests and Annotate your code So this is what the command line looks like you say puto generate give it a bunch of arguments It creates a unit test for your module Similarly for annotate you say puto annotate and it annotates all your code But how does it work? Puto works by monitoring code execution very much like a debugger It creates a hook in the interpreter using sys set profile and once it gets a callback for a function of interest It captures a bunch of metadata from that from that call the things that it captures are things like function argument values return value and Argument state before and after the call and while it's added it actually also captures the type information for that call And it does that every time the function is called once it has all this metadata It is able to create unit test and apply annotations So let's look at an example. This is a lighting talk. So the example is going to be very simple There's an account class and there's a person that uses the count There are a bunch of methods that don't have any testing and we want to create unit test for all of them Simple we say puto generate you give it the set of functions you want testing for You provided the module name in this case the functions are all the functions in person class you give it the module Which is obviously person you give it an output file and you give it a way to actually call these functions Now this is that in this case is main So this could be an integration test for your application or this might be handcrafted test In this case main just creates a bunch of person objects and invokes functions on them Cool. Once we run this command you have a unit test that is pie test compatible. How does it look like? Like this so we create a data-driven test We collect data for all the calls to the method in this case I'm showing only at friend, but it generates for all the functions all the calls to add friend are captured and using the parameterized Decorator in pie test we create a data-driven test What do we capture we capture the state of the object before in this case? We have a person named Mary who we are adding a friend named John Which is the second line the return value and the state after After after the call we use json pickles to capture the state of complex objects Because pickles easily allow us to store the value and recreate an object and also because json pickling Makes it very easy to add test by hand Now we can run the pie test and you can use the coverage plug-in and by doing that We went from 0% to 95% code coverage like that But that's not all we can also annotate our code similar to that we provide similar arguments to Pew to annotate we can tell it to override the code We can tell it to use type annotations in python 3 or type comments in python 2 This is what the annotated code looks like Okay, there are certain caveats because this code needs to be run like a debugger. It is called in process All the invocations the data is real-world data, but all of them are treated as baseline. So if you function as a bug You it will be treat it won't be caught by pewter in generated code most importantly will require inspection and augmentation So right now we are using pewter internally it works even for fairly complex classes We have a database microservice that use a sequel alchemy and we can get almost 60 to 70 percent code coverage for its unit test We do want to internally release it and maybe release it to wider audience at some point So do visit us again at blue at our booth g7 to find out more about pewter and Bloomberg. Thank you very much