TDD upside down or how to cut corners (in Russian with English subtitles)

I don’t know if you’re ready for test driven development But let’s go for it There will be four ideas The 1st idea is a frequent misconception among developers I think you all know what tests are They think that automatized test are an addition to the program code This is a popular view I often here excuses, ‘We don’t have tests’ Who has tests as a regular process in code development? More than a half I often encounter developers who tell me their company doesn’t have tests Because they don’t have time, money, other reasons Because there’s no customer’s wish They lack something, so they don’t have tests I think it’s a misconception People see tests and code as two separate units My idea is, they should be a single unity I gave this example during my Next performance There’s safety net When electricians work on a high-voltage cable They spread a safety net under themselves If something falls, it will fall into the net, not on the heads of whoever walks under Or when athletes train to do tricks, they have a safety net below They make flips, not worrying about falling Unit tests, or automatized tests are the same safety net It’s impossible to say, ‘We are making flips without a safety net, cause we lack money’ It would be weird if athletes said ‘We don’t have the safety net for now, cause we don’t have time to install it’ This is how I see programmers who write code without tests I think it will be slower, not faster without tests You can learn to make flips or fix the cable without the net But we’ll always fear dropping the tools They’ll be falling, we’ll be going down to pick them Tests and code should be one thing That’s my first thought that people often disagree with I know one main reason why people don’t write tests: they don’t know how to One has to know how to write code and tests Here’s another analogy It’s possible to write Java code in a text editor Or it’s possible to use IDE That simplify and improve the process Everyone knows how to do it in a text editor It takes some time to learn how to use IDE One can say, ‘I have no time to figure IDE out, so I’m using a text editor’ But that’s wrong logic Since if you figure it out, writing code will be faster The same goes for tests That’s my first thesis My second idea is about TDD Everyone knows what it is, right? Test Driven Development First, we write a test Forget the first idea The second thought is independent Test Driven Development is, first we write a test, then we write the code There are two ideas in regard to this I’ll show you two slides You know this developer, right? How many people know him? This is the author of Ruby on Rails This is what he thinks about test driven development I tried to translate it into Russian I think I managed to convey the meaning He’s absolutely against the test driven development I think he’s against automatized tests in general That’s what I think after reading his articles Maybe I’m wrong But he’s totally against TDD He thinks it’s harmful He thinks first writing a test, then the code is stupid One has to write the code at once Tests should be written afterwards, or not at all That was the first opinion There’s the second one You know who this is, too, right? Bob Martin, ‘Clean Code’ – you probably read the book He has the opposite idea Absolutely different He thinks that test driven development is correct First you write tests, then the code As for my personal opinion I don’t remember what the next slide is My idea is, TDD is correct But it should only be applied when the project has reached the stage of experimental prototyping I even drew a picture that I’ll show you now about the correct application of TDD When at first, we have nothing, just blueprints of the code Then we get bugs, errors, problems So we begin writing tests + the code as a response to them This is how I use TDD in my projects

I’ve been trying this for the past 4 years of work I made a tool for this, I’ll briefly tell you how it works It does prove the hypothesis I’m about to show you The hypothesis is, when we have no code, nothing We can’t write tests, it’s really stupid We’ll be losing time It’s impossible to setup the safety net everywhere It’s impossible to spread it over the whole surface To foresee where the flips will be done, where people will walk We can’t make the net large So, we try to make the flip for the first time We’ll try to implement the first part of the code Then we throw it into production or to some test platform We see the result Then we receive feedback We start working on this model This is how the scheme looks into he picture I write code I write code that should work on my machine Without tests No TDD at first, it’s impossible I agree with the fist opinion It’s impossible to write test first if you have no code This idea is impossible to work with Something happened to the font This is not how I remember it Maybe it’s a good illustration We deploy like this There’s no test here, we deploy it somehow without a test That’s all Then we try to invite users, we can be them as well, or real ones Or they can be testers, anyone Consumers of our system They start to break this system Use the system, break it, see the problems They see defects, errors They report these defects They break it, bugs appear They report the bugs They say, ‘It’s not working here and here’ If I’m a developer, I can do that too I deploy it, I see the formatting is wrong I write a bug, ‘The formatting is incorrect’ Then, TDD occurs Then, I write a test as a response to this bug Then I fix the test First test, then fix And this is how I finish the cycle Sorry The cycle ends here, and starts again First, I wrote something that no one tested I didn’t need tests there Then, I deployed it And when someone started breaking this product, as a result the necessity to write a test appeared This is the idea that many people disagreed with at the conference Many people asked how it’s possible to deploy like this ‘You deploy without tests!’ My idea is, until the test is needed, until there’s a bug Until someone reports a defect There’s no point in writing a unit test We don’t fix the net before the athlete falls for the first time We have to arrange the net as a response to the fall He falls here and there So we fix the net But we don’t do it the other way round We don’t first spread the net, then wait for the flips They fall first, then we fix the net As a result, it acquires the shape that the business needs If business requires fixing the formatting here, we’ll fix it And if everyone agrees, no one reports a bug This will do There’s no point in testing more than necessary I write in Java, Ruby, PHP, Java Script, and in Python a little This is how I make unit tests everywhere I don’t do them at first, then I do them First deploying, then testing, yes This is the right question This is the main concern, the main problem everyone started telling me about How do you release it to production, and then The definition of production It doesn’t mean that I am a developer here and there’s my real client, standing with a bank card in front of an ATM And I deploy my code into the ATM at once The code will go through a lot of production stages before getting into the ATM First, my colleagues programmers get it Then alpha testers

Then beta testers Then staging platform And only then it reaches production I receive feedback with defects during all those stages I keep receiving bugs If the business is so stupid that it connected me, the developer directly with the ATM, the production That’s the fault of the business As a developer, I should deploy everything without creating extra tests if the business doesn’t need that If the business says, ‘This quality works’ ‘Let it be, just draw a slide’ I did it Why should I waste time on the slide, if the business doesn’t need that? And if the business built 18 testing levels between me and the ATM And I receive dozens of bugs a day during every one of them It means, the business wants it, and I’ll have thousands of tests written as a response to the hundreds of bugs That’s my logic Here, look what I did I wrote a procedure of login, and wrote a test at once just to check that it works tests can be used like that To somehow verify what you’ve just done in an automatic mode, without clicking the mouse You check what you do before deploying it somewhere I agree But in this case, we become the testers for ourselves Yes, yes If we have the need to somehow check what we wrote, we are already in the cycle It means, we already started testing something We want to try this login It happens in my practice Small tests should be added sometimes As for what I did I took a few dozens of my projects Different ones, open source and commercial I wrote a small tool in Ruby command line It goes through the guide history of these projects It checks the insensitivity of commits to the different sections of the repository If it’s in Java, whether it’s ‘src/main’ or ‘src/test’ Whether we were committing the main code, or tests I compered them Is the logic clear? We take the whole history and see where it’s more intense We place time horizontally and vertically, the percentage of the location of the repository where tests are How intensively we were committing tests You understand what we want to get, right? I ran a few dozens of my projects both open source and commercial I took many projects from the market I showed any graphs in Moscow, I won’t do it here Just believe me, they all look more or less like what I’m about to show you Like this At first, the percentage of tests is small In my projects Open source projects We took Java and .NET Then, there’s rapid growth within a short time period It depends on the project, it’s a month, two, three If, for example, this project lives for two years It’s a couple of months There’s a sharp increase in the number of tests Then, it becomes stable Depending on the project, it stays on this level of 20-30% It’s 5% for bad projects I saw the figures from 5 to 30% It proves my theory that everyone does this It’s not just an idea, it’s a practical approach We really cannot write tests at first, because we don’t know how to It’s unnecessary, we write a lot of code Then, when it’s all compiled and we deploy it to some production They start breaking it intensively here There are a lot of things to break, it all works bad Not just login forms, everything Then we keep fixing and stabilizing it And then, there’s the same intensity of committing bugs Every time we receive a bug, we add a test and fix it That’s the idea Another couple of slides Two more I summed up this idea There’s no point in writing tests, if no one needs it If no one is complaining If no one says that the code is bad, that it’s not working Another important idea Most often, people view the bug as ‘He put his card into the ATM, the ATM devoured it’ It’s a serious and critical bug, but it’s only one type of bugs If I wrote a code, and it’s unreadable And if my colleague sitting next to me cannot understand the design of my class, it’s another bug If someone cannot find the documentation for this class, it’s another bug If someone sees that the sorting could be done otherwise, it’s another bug A bug doesn’t mean that everything failed and we cannot launch the system That’s not the only type of bug Bugs can be different From minor to major bugs From important to less important

There’s a wide range Everything that’s bad in the product In the documentation, design, architecture usage, functionality choice of a platform, choice of a database Why MySQL, not …, it’s another bug Why the solution is not described How the team made a decision Bugs can be many The more bugs there are, the better The longer the pipeline between the developer and the production, the final ATM the better The more bugs it can generate, the better The more feedback we can receive from it Before it reaches the final user The longer and faster it passes, the better There should be a long chain of different forms of testing that returns different bugs But it should pass as quickly as possible That’s the idea As I just said, there should be numerous levels and sources of these bugs Before a user gets a chance to see our product in the end That’s my idea I have an article in my blog where I showed all the graphs This is the link, you may take a look It’s all described there That’s all about the test driven development I have a question about statistics For example, if there’s a commit There are both code and test in the commit Is that 50/50? No, we count depending on the number of lines of code We check how many lines changes in this section of the repository The number of lines that changed If we receive a commit, and we change 10 lines in the main code and one in the test, it’s 10 to 1 We check the number of lines of code that have been changed My question is not about performance, it’s about the process Have you ever placed bugs on purpose? Bugs? Yes, on purpose When you have a long-term contract Don’t laugh, you don’t know what I’m talking about Don’t laugh You have no idea what it’s like, working as a System Administrator in a government entity When you’re employing an agency that makes bugs on purpose To keep receiving their salary That’s what I’m asking about You can laugh afterwards The idea is good I’ll repeat the question Does it happen that developers place bugs or leave them in the code to receive additional contracts for fixing the bugs? It makes sense, but I never did it But I can imagine the motive I’d probably do it if I had a big agreement with a state entity It would probably make sense Because why not The question probably isn’t about the morale It’s probably about the incorrect process of assessment of my work If I am writing the code as a contractor I give the code away on the contract And then a number of bugs is found in it And that number is You see, it depends on the contract If according to the contract, I have to give away results, blocks of functionality I am paid for these blocks That’s one thing If I am paid per hour and I just receive money for sitting in front of the computer It’s a different thing It’s about a person sitting in front of the PC who makes bugs happen all the time in the code to preserve the contract Is that the idea? My answer is, it makes sense then, I’d do it, too I’d do that, I’ll say it into the camera, it makes sense If such an agreement was made And I am paid for the time spent in front of the screen I’d try to extend this time It makes sense, anyone would do it I’d leave bugs, of course Maybe, I’d create them on purpose But it’s the fault of the one who hired me He makes a mistake by hiring me on such terms Paying for my time, not results And it’s his fault, so let’s punish him, let’s leave bugs Well, yes, the state Thank you for your report

You are like, oh, enthusiasm, you begin writing code You don’t write tests And it works, bugs don’t come as a response And you’re asked to develop new features How afraid are you of developing them? You don’t have a single test Or do you start writing tests at that moment? Losing your enthusiasm since you have to write even more of them How is it? Yes, I’ll repeat the question The idea is, we first wrote some functionality Then, nobody tests it It’s somehow accepted Worse than that, it was tested, and it works Yes, it was tested, they pressed a couple of buttons, it works There’s no deep testing I doubt it’s possible to write functional at once without bugs They are there, they just weren’t found Then the order comes to extend the functionality To add some features We open the code that has an almost zero number of bugs Which means that all the bugs stayed inside They just weren’t found Now, I open it, I have zero tests, a bunch of bugs What do I do with it? The situation is bad It’s the fault of those who made the pipeline short Allowed my code to be deployed in production and used But used it poorly, determining few bugs Now, we have a very raw product It’s very bad Can I ask another small question? It means that there cannot be no bugs in a code? There can’t be none, of course As you’re saying, they are many An infinity of them And when you’ll be developing a new feature Your code already was tested, there were bugs You wrote a lot of tests That’s the right way, yes I’ll make myself more clear I actually think that there’s an infinite number of bugs in every code Even from the point of view of math The symbol of eternity If you define a bug like many documents define it As the inability of the product to meet our expectations and requirements Requirements and expectations Expectations are an infinite entity Take a look at any product, no matter how perfect it is, you can break it You can always find inaccuracies in the code Inaccuracies in formatting of the code Insufficient documentation Try to launch the product on Windows, not Mac It won’t work there There are numerous ways to break a product The number of bugs is infinite The question is, what number of these bugs is visible to the user Which of them we were on time to find If we found a hundred, and a user found 2 in production, in the ATM That’s one quality of our software If we found 6,000 bugs, and a user found one That’s another quality of our software If we found 14, and a user found 100 That’s again another quality And if we found zero, accordingly, we can predict how many bugs a user will find – many We need to play with these two figures The first figure is how many bugs we managed to find and fix And the second figure is how many bugs came to us from the end user To reduce the second figure We can’t reduce it to zero, it’s impossible Because the general range is infinite So there will always be the field for bugs found by a user But the more of this field we cover Of course, we cannot cover infinity We can try to reach the big numbers The better Of course, when I receive a code in which 3 bugs were found And I have to work with it I realize I’m dealing with a complete mess I am dealing with a code that’s not suitable for work There are too many bugs in it now No matter who wrote it, no matter what a wonderful programmer it is That’s why I think that’s the mistake of the business, the organization Hi, thank you for your report Here’s my question Nowadays, there’s more and more software that doesn’t just follow instructions It also performs data analyses It works with large databases Recommender systems The value of bugs in these systems is great Because if you allow a bug into it It might become evident at the millionth user And the re-indexation of the database, overfitting of the model will take time In your opinion, which corrections should be introduced into your approach in this case? What should one think of to try and avoid it? I think that I think that the quality of the software can be improved not by improving the quality of the developers I might say surprising things But I think it’s not improving the quality of programmers Not changing one programming language to another Not changing one technology to another These things won’t increase the quality of the software

They won’t reduce the number of bugs that a client will find The quality of a software is the correlation between the 1st figure and the 2nd one To make the second figure smaller, we need to increase the first one To change the correlation We just need to increase the first number Then the quality improves a lot More bugs to improve the quality To increase the number of bugs we need to make the process of our software reaching the client harder It has to overcome a lot of obstacles and difficulties called testing on its way to the client Testing can be different You can launch statistical analyses, a security checker Setup SonarQube It will run through the code and find bugs automatically You can place manual testers who’ll be pressing buttons from morning till night You can hire a code reviewer Who’ll walk the code from morning till night looking for bugs You can build a staging platform One more ATM before the real one to test everything on it There’s a million of options Write integration tests We won’t discuss the types of testing They should be many Why should they be many? Not to prove that our code is working But to break it The more systems breaking our code we build The bigger will be the number of bugs we find It means that we will increase the correlation between what the client finds and what we find That’s the idea What system will it be? A payment processing for the government Big data, or a system for launching satellites It doesn’t matter, the logic is the same The more obstacles there are, the higher the quality is That’s what I think In most cases, there are no such obstacles Because people think the opposite They think bugs are bad The fewer defects there are, the better their quality is Take every other person I’m communicating with The thing the fewer bugs they have in tracking, the higher the quality of their software is The fewer bugs they show to a client, the happier the client will be But that’s wrong The client should be happy That you show how many bugs you have Ho many defects you found How many inaccuracies there are How many comments on design and so on there are But mostly people do the opposite They say, they found 2-3 bugs, and that’s great It’s the 5th time I’m telling this I knew a guy a few years back He was telling me about his high-quality system They were developing the software for 2 years And they only had a thousand bugs reported I asked him whether that was good or bad He hang up He realized I was trolling him But I wasn’t trolling him It’s wrong to say, ‘We only have a thousand’ You should say, ‘Imagine, we found 5,000, and we keep finding them!’ ‘How awesome and powerful or testing system is’ It doesn’t mean that a programmer is bad, if there’s a bug in his code All programmers create bugs Moreover, I think the more professional a programmer is, the faster he or she creates bugs But that’s another topic Yegor, thank you for your report A lot of interesting things were said today I realized that Javaists like to write in Ruby You know, as a representative of the Ruby community I’d like to ask an interesting question Very interesting topics have been touched, indeed As a person who mastered TDD a year and a half ago I came across this problem I’ll make an introduction to the question It’s possible to say that Ruby community has set a standard of testing When we have many options and places for testing But the question that concerns me a lot is Different people test in different ways Controllers, models, module tests What are the best testing practices and what should the culture be like to be on a good level? From what I can see, there’s no such culture now I got it, I got it The question is, how to make tests of higher quality? This is a good comment and a wide topic Just making tests may be bad If there’s a complex pipeline ahead They send us bugs Then a programmer creates a net from the bugs The safety net But does it poorly Instead of being the safety net, it entangles the product As a result, it gives false signals The goal of tests it to give true signals To be the first ones to say that something happened It should signal about a problem on time And not signal if there’s no problem The typical problem with tests is, people write them in such a way that

they become so closely bound to the code It one of the typical mistakes The test and the code become so entangled That it’s impossible to fix the code without throwing out the test It appears that a class lives with a test And they become a unity which shouldn’t happen Tests should be independent from the implementation of the class, the module A test should only test the external behavior of the module Not its inner realization Most tests are written in such a manner that a test almost fully depends on how the module is implemented with a help of mocking, super mocking, other technologies Naturally, if I begin modifying the module The test fails The test begins to call false positive signals It gives a signal that the module is broken Even though I changed the logic, not the result For example, I have a list sorting module It used to bubble sort A test checking that it’s bubble sorting has been written I rewrote the module Now it does binary sorting And the test says that it’s not sorting What should I do with the test? I can’t fix it, I don’t have bubble sorting anymore But the test signalizes, false positive, in red light What do I do? Get rid of the test Someone was writing this test at some point, invested money into it Someone received bugs from production Saying it doesn’t sort Bug came from a user We spent money to find this bug We launched a staging platform We built an ATM As a result, it reported that transactions aren’t sorted The bug came here a year ago Someone spent money More money was spent on all this than on the unit test Someone wrote a unit test for this bubble sorting It’s all great, the sorting was fixed It began sorting, it was deployed into production All good I open the class in a year I write new sorting, not bubble one, the test fails I skip it In the best case In the worst, I just delete it It means, I multiply by zero all the investment that has been made All the way of testing Everything has to be done anew I have to make the same way again to the client, to the ATM, etc That’s the problem Instead, the test should be working if the algorithm of sorting was changed So that the investment isn’t wasted That’s the comment on the problem How to write tests in the right way? Google unit test anti patterns, you’ll find 30 of them I can’t say anything definite about the culture of tests But we write unit tests in Ruby, in Java Okay, I’ll talk about this briefly I think that the division between unit tests, integration test, and feature tests is artificial I’d take it away from the industry I think that there are just automatized tests It’s very hard to say what’s an integration test and what’s a unit test Almost impossible So I think people make an artificial division Integration tests are when working with a database Unit tests are when only working with a module And if I get rid of the dependency It’s a unit test And if I leave the connect to the database It’s an integration test What about a file system? A file system isn’t a database What about memory? It’s a conditional division into business levels Let’s call test we write for the classes that start with an ‘a’ unit tests and tests for classes starting with ‘b’ integration tests I think that all tests are equally automatized It’s visible in Java It’s less evident in Ruby Because in Ruby, there’s the cucumber Separate testing Feature tests They are different, they look different, they are written differently It’s all the same in Java All tests are written in the same way They are only different in suffixes and are launched at different stages of compilation Their core is the same Hello, thank you for the report A question for your previous monologue Should there be a correlation between a big number of bugs You gave an example of a big number of bugs If the number of bugs is extreme Maybe it would make sense to change the team? Maybe yes

Are there any signals saying that it’s enough? When there are too many bugs? When there’s a lot of bugs, we keep debugging them, but where’s the result? Should there be a correlation between the result and the number of bugs? That’s a good question How to measure how the team is writing When we deployed something to production and there’s such an intense stream of bugs When the price of fixing grows and grows I think it’s a purely financial question It just never happened to me I’m trying to think of what I’d do in such a situation It was always the other way round with me In my whole practice, I don’t have enough of bugs For years, I’ve been trying to hire people who wouldn’t test manually Those are easy to find To hire people who’d open my code Look at it and write what they dislike about it Seems like a simple job I posted it on oDesk, on Upwork, on different resources I was doing it all for money, I’d pay a lot for that But I was paying for bugs, not per hour I would say, ‘Write what’s wrong, report to me, I’d pay you $20’ What’s difficult? What you dislike, what’s unclear to you, what you’d like to change It doesn’t have to be not working Our code is good, it’s in production, it’s working The system is working But here’s the source code, what would you improve? I couldn’t manage to do that, I gave up on this idea half a year ago I don’t know It’s not likely that there’s good code Even though the code is good, yes But people come, sign a contract with me Receive access to the repository These are real stories The gain access to repository In two weeks I ask about the results ‘I’ve been busy’ Or they’d write about 1-2 bugs, and that’s all I’d say, I’d give you $20 for a bug Spend the whole day looking for them You don’t need to write anything Give up on other projects Here’s me, I have enough money, I’ll pay you $20 for every bug Find 10 bugs a day, receive $200 a day That’s all! They can’t I can’t understand why I always have the opposite problem I don’t have enough bugs I am ready to pay for them like this No need to run complex tests Just show what you’d improve in the code, what is unclear to you It was always the problem, programmers wouldn’t have a problem coding When hiring programmers, I’d tell them I’d pay them if they kept an eye on the neighboring code and tell me what they didn’t like about it Maybe the skill isn’t developed in programmers Apparently, we’re more constructive than destructive That’s my suggestion Psychologically, we want to create, not destroy So when we look at other people’s code, we don’t want to offend them Maybe it’s hard to criticize I tried Ruby, Java, Android Platform A few people wrote to me We can meet after the meeting, you can give me your GitHub account I’ll make an experiment and post the result on Twitter And we’ll see In a couple of months, I’ll write how many bugs have been found I’m sure there will be less than ten figures, we can try Okay, let’s try I have five Ruby projects, they all need this job I could do the same I also write fake servers and clients, I didn’t find another solution I even have libraries I created myself

Libraries that make a fake server Libraries that make a fake client if needed Then you join them It’s unclear whether it’s an integration or a unit test Since you integrate it with some server You can mock databases like that as well I have a project that I was working on this morning The project connects with DynamoDB That’s a NoSQL database on Amazon You can test it with real data bases That will be an integration test I rise the H2 database And even though H2 is relational I have a library that makes a NoSQl out of a relational database in a test mode It’s not fully functional It makes it look like DynamoDB I wrote this library a couple of years ago, I’m using it now Testing always supposes I’d like to develop this thought since we stopped at it I’d like to say that When I receive a bug from my pipeline The process of writing a test that will repeat this error Is the hardest stage for a programmer Here’s what happens At first, I have a piece of code There’s an automatized build in it There are some tests in it There’s some test coverage The code is somehow covered A bug comes then And the bug says, ‘You transactions are sorted not by date, but by whatever’ The bug is clear A client got a slip from an ATM, and transactions are sorted not by date, but randomly What does it mean? Only that there’s a hole in my safety net My code, covered in tests has a defect But the defect is not in the code, it’s in the coverage It means that the code managed to sneak into production through this safety net It’s the fault of the net, not of the code We shouldn’t blame an athlete for falling when making a flip, but the net with a hole My first step is to understand where’s the hole in the net and to patch up the hole As soon as I patch it, my build will become red Test #14 that I’ll add now will gleam red That will be my success Then I’ll fix the system bug In my experience, the time and effort spent on the first step on patching up the hole in the safety net on repeating the problem from production in the test It takes 80% of time And 20% of time goes on fixing In my experience, the older the system is, the bigger the code is Tests appear to be more complex and bigger They are harder to create The fix itself is usually one line or one character Or one figure You change 2 to 1 But we can’t just change it to 1 and deploy it into production again We don’t solve the key issue like that We don’t patch the hole, and we’ll fall into it again Something will happen again But that’s what people usually do A bug comes, they open it, see that they need ‘1’, not ‘2’ They change it to ‘1’ Build, deploy, it goes and works It’s sorting Let’s go home But that’s not a professional approach We have to replay an error in a test every time And that will take more time than everything else Writing mock servers and mock clients Sometimes, you have to write a whole framework to repeat the error I had this problem 6 years ago There as a project in California with a big volume of data It was data processing A huge array of data in an XML would come We had to import that XML into a database, Microsoft SQL It was possible to write it Coding wasn’t hard Testing was an issue since it wasn’t stable enough We took DbUnit, it was a Java project at the time It’s a framework for testing operations with databases DbUnit didn’t suit us, I don’t remember why We had to write our own framework and even make it open source Only to test one system To create tools to repeat some error Only to test one system To create tools to repeat some error But you can imagine, the fix itself only took a couple of lines of code, adding a couple of classes We spent a lot of time on creating the safety net Then, it’s easy to make a flip if the net exists Since we came to big complex tests, is it necessary to write tests for big complex test?

The answer is yes Obviously, within one project, the answer is no It would have been silly I’ll go back to the previous example The framework we created was surely tested We were creating a framework for tests Take JUnit, it’s covered by tests There’s this another good idea, look If tests are good, they should exclude code duplication themselves It won’t be good if we have these test scripts written with a lot of text that’s hard to maintain and understand Code should be maintainable If you begin writing big tests, you’ll see you’re duplicating the code You’ll want to exclude some blocks and make some utility classes or objects out of them Some additional elements They won’t be tests, they’ll be mock servers, for example For example, you want to make an HDP server that will always listen and answer OK You’ll want to use this server with an OK response in 15 places of your code It would be good to write a unit test for this server Or it would be like that joke ‘Doctor, no matter where I poke with my finger, it hurts’ ‘It’s cause your finger is broken’ It’s the same here If your mock server isn’t working and replying 404 instead of OK And you use it everywhere You’ll have 10 broken tests You’ll be fixing them all one by one That’s wrong Which is why it’d be good to cover this module in an additional test In such cases, I try to make it a separate project If possible If we see that there’s some module that I created for testing why not post it in open source It’s likely someone else needs it If it doesn’t exist in the market, let’s publish it If it’s already in the market, let’s check we’re not inventing the wheel Maybe someone’s already using it, we’ll take it So the answer is yes, we need to test the testing modules Yes, I understand the question But in short, we don’t show it to the customer We don’t explain it I am often asked this I don’t think you need to explain to customers what test driven development or a unit test is They won’t understand it They’ll require that they aren’t present They’ll ask why so many tests if it’s already working But it’s like explaining to a customer why I need to buy IntelliJ IDEA for $450 I can’t write without it While another programmer writes in a text editor It’s hard to explain to a customer So it’s better to take money from one and say, ‘This job coasts this much’ We try to evaluate the result in blocks, in micro tasks Micro tasks are always like, ‘Fix a bug #13’ We’ll surely fix it with a unit test With a code review, and a second code review, for sure With deploying into a stage platform We won’t tell a customer ‘We’ll charge you for deployment, code review, and for unit tests’ We just say, ‘We’ll charge you…’ No, we don’t have any other option, we don’t do it any other way I cannot manage a programmer differently if he’s not writing tests Everything falls apart then I can only manage a programmer if he follows these obligatory procedures He’ll pass statistics analysis, his code will surely have a test There will surely be 2 code reviews And then it will be automatically deployed to production Will all go through automatic procedures If this full cycle is lacking, I don’t know what to do with the programmer He becomes unmanageable The customer is not the problem here I shouldn’t be allowing all sorts of trash into my master branch Then I’d find myself in an unmanageable situation It will no longer be a matter of $2 for the tests The project will fall apart So it’s easier to tell the customer to mind his business ‘It costs this much’ ‘If you want to find someone cheaper, you’re welcome’ ‘But with us, every bug will cost, say $100’ Of course, you can exclude unit tests for $12 from them, code review for $13

Exclude something else for $27 As a result, I won’t be able to compile it as an architect Of course, there are teams that develop without tests I met many of them They probably have another developing process I am talking about my approach One last question I still don’t understand why during the first stage, before deployment there’s no need to write tests for your server For instance, there are typical tasks that this code should be performing It’s possible to write two unit tests for this couple of typical tasks that will sure prevent the appearance of these two bugs that will later cost, say, $200 To write minimal tests at the very beginning I’ll try to explain this This stage, the first one, is usually very short It’s not months or weeks It’s 4-5 days It’s one programmer’s intensive development in front of his PC For example, when I’m doing it I am absorbed by a problem, I know how to solve it I make it all launch on my PC I don’t see bugs here If I saw them, I’d fix them, I don’t need tests for that I can see that it’s sorting, bubble or not I press the button, there are 3 transactions, it’s sorted Yes, maybe it won’t sort a thousand But it will sort 3 Why should I think about the future, what will it do with a thousand? Should I write a test for it? That the issue of the next cycle I have 3, 1 sorted, and it’s great I saw one being sorted – that’s all Why should I think whether it will sort 2, 14, 400, what happens if there’s ‘out of memory’? There are all these ‘ifs’ Why should I launch the cycle that no one paid me for? Maybe, indeed, the customer will take a look at this piece of code, this sorting and won’t need it, he’ll exclude it We don’t know the customer’s request yet We should work for money and for result We work for the client, not for ourselves If a customer needs our piece of code We refine this piece of code, make it better and better Until there’s a sharp need from the point of view of money, business There’s no need to cover in gold something that shouldn’t be covered in gold So here, when I develop, it’s 3-4 days And everything will work on my machine It will work like it does on my PC Then, of course, it will tell on the server It will show ‘out of memory’ at great load on the server It will go to stack overflow All of it will happen there But while it’s alive here, I’m ready to deploy I compile the slides and sent them here There’s no need to launch much in 3-4 days I’ll fix it, I won’t write a test Why not fix the code at once? This is a code, I know where the error is It’s already 3 hours? For me, it’s 3 days That’s all