TDD : DO I reallly needs to learn it ?
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
When I first heard about TDD I couldn't figure out how it was different than what I was doing already ... write a bit, test, write a bit more, test. TDD allow me to formalize what I was already doing by making it easier to write the unit tests I had to write anyway, and these represented a way of passing the torch on to the next person who had to maintain what I wrote, because it documents your assumptions that another developer can easily read. Proof of TDD came on a project where I had to write a complicated calculation engine consisting of perhaps 15,000 lines of code and tens of thousands of inputs. The system was delivered with just two bugs, and both bugs were because of specifications they never told me about. I'm pretty thorough as it is with my software, and have few bugs in general but to know precisely there were only two bugs made me pretty proud. If you are working with others and have to hand off your code, TDD is the way to go. If you have to write unit tests for your code, then TDD is definitely the way to go. Unit test writing after you've written the code is as dull as watching paint dry. But I found that writing tests as you developed didn't feel like writing test cases at all. To know you haven't introduced bugs into your code is also a big benefit. There is a certain kind of pleasure to see all your tests continue to pass green each time you run them too. As to whether you want to learn it or not is really up to you. But if you have to hand off code, or you write code that is very complicated, I think you're foolish not to use TDD. My two cents.
-
Yes, you are definitely missing something. The 4000 users number isn't very indicative of when to use TDD. But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features because your users don't want to wait 3 years until all of them are finished. In that case you need some automated testing.
Wout
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
Not from the guys that advocate TDD. Unless... well, no. A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool? Baaack to the topic: it is worthwhile to write unit tests as an exercise (i.e. repeat often, on different topics). This not only teaches you to write them (always good to have some around) but also what code lends itself well to them. if you feel confident, try writing them before the code and see for yourself.
The problem with the TDD crowd is that they are so enamored with it that they now consider it a test driven design. That's right, by writing your tests first, you will end up with a good design.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool?
No. best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
When I first heard about TDD I couldn't figure out how it was different than what I was doing already ... write a bit, test, write a bit more, test. TDD allow me to formalize what I was already doing by making it easier to write the unit tests I had to write anyway, and these represented a way of passing the torch on to the next person who had to maintain what I wrote, because it documents your assumptions that another developer can easily read. Proof of TDD came on a project where I had to write a complicated calculation engine consisting of perhaps 15,000 lines of code and tens of thousands of inputs. The system was delivered with just two bugs, and both bugs were because of specifications they never told me about. I'm pretty thorough as it is with my software, and have few bugs in general but to know precisely there were only two bugs made me pretty proud. If you are working with others and have to hand off your code, TDD is the way to go. If you have to write unit tests for your code, then TDD is definitely the way to go. Unit test writing after you've written the code is as dull as watching paint dry. But I found that writing tests as you developed didn't feel like writing test cases at all. To know you haven't introduced bugs into your code is also a big benefit. There is a certain kind of pleasure to see all your tests continue to pass green each time you run them too. As to whether you want to learn it or not is really up to you. But if you have to hand off code, or you write code that is very complicated, I think you're foolish not to use TDD. My two cents.
+5 Of all the replies to this thread, this seemed the most specific, the most reasonable, the most eloquent, the most practical ... to me. thanks, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
Do you think Picasso made TD works? Even if you aren't such an artist, but feel yourself like a good little software artisan (or at least you have such an illusion) then TDD may be more pain than advantage. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Actually, to some extent, yes, I think artists in general do use some kind of test system and 'agile development process': they sketch their idea on a slip of paper, then on the canvas, maybe discuss it with others, and focus to fix the idea of what their work should express in their mind. They usually don't care all that much how every shade on the image looks, but how it contributes to the overall expresssion of the work. They may not actually write test cases, but they do work to a very specific goal in their mind. It may be less obvious when you look at the more extravagant artists and how they work. but I'm convinced that they, too, have a very clear idea in their mind of what they're about to create when they work, even though to others it may not appear so. And they do, regularly, pause to check whether their creation so far is on the right way to what they had in mind. You could consider that some kind of testing.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
I used to think that one-person projects are small enough to get away without the effort of extensive test frameworks and similar advanced measures of QA. And the projects I've worked on appeared to confirm my beliefs. But when I started setting up a unit test framework for a small library in an attempt to introduce testing for a larger app, I realized - even before implementing the tests, just how much more I started considering about the inner workings and special cases. In other words, just thinking about what to test made me realize a number of things I otherwise wouldn't have until much later. Or at all. Thinking about each individual test and how to guarantee the preconditions for each, forced me to think through the whole collaboration both within the library, and with other parts of the application. Once I had all the test cases covered, I knew my library classes would have all necessary functions (at least the public ones). If I had gone about it without concern for testing, I would have forgotten a lot of functions and would have to add them later. TDD also made me realize that a few functions that I thought I'd need and added to the class interface, weren't needed after all. Finally, the realization of what was really needed, and what not, helped me make a couple of very important design decisions, before creating the classes, e. g. where to use inheritance, templates, or neither, or that a particular class actually wasn't needed. So to conclude: You may not need TDD for small projects (or even moderate large ones), but using it will influence your design decisions and could give you a better understanding very early in the development process. I do believe that TDD will give you a better design. What I can't tell you though, is under which circumstances the additional effort is actually worth it. Often the second best design is good enough. I guess you could tell better by experience - so it probably would help you to get some. :)
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
What is TTD actually? I never heard of it..
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
Mostly I try to stay away from projects that are large and formal, because it doesn't quite fit the way I like to do things. I like projects where I do little testing and the environment is small enough so I can release a patch within a couple of minutes. But in case you're sending a rocket up to space, you'd better have some evidence that you tested the code. Also in health care often you need to keep records of your software tests, so guys from the FDA can come in and audit your software process. In some cases you can even prove mathematically something works, but I have never seen that being applied in the real world.
Wout
-
I used to think that one-person projects are small enough to get away without the effort of extensive test frameworks and similar advanced measures of QA. And the projects I've worked on appeared to confirm my beliefs. But when I started setting up a unit test framework for a small library in an attempt to introduce testing for a larger app, I realized - even before implementing the tests, just how much more I started considering about the inner workings and special cases. In other words, just thinking about what to test made me realize a number of things I otherwise wouldn't have until much later. Or at all. Thinking about each individual test and how to guarantee the preconditions for each, forced me to think through the whole collaboration both within the library, and with other parts of the application. Once I had all the test cases covered, I knew my library classes would have all necessary functions (at least the public ones). If I had gone about it without concern for testing, I would have forgotten a lot of functions and would have to add them later. TDD also made me realize that a few functions that I thought I'd need and added to the class interface, weren't needed after all. Finally, the realization of what was really needed, and what not, helped me make a couple of very important design decisions, before creating the classes, e. g. where to use inheritance, templates, or neither, or that a particular class actually wasn't needed. So to conclude: You may not need TDD for small projects (or even moderate large ones), but using it will influence your design decisions and could give you a better understanding very early in the development process. I do believe that TDD will give you a better design. What I can't tell you though, is under which circumstances the additional effort is actually worth it. Often the second best design is good enough. I guess you could tell better by experience - so it probably would help you to get some. :)
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
-
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
-
I used a small project a few years ago to try out TDD. Pros: * I learned a lot about writing useful unit tests, not just the "does it handle a bad argument in the method" garbage most unit tests seem to do. * It got me thinking about architecture much earlier * It got me thinking about functionality and it was neat to have stubs for various classes and methods, and as the stubs got filled in with actual code, watching the little red lights turn green. * I enjoyed thinking about things from a different perspective. Cons: * There's a disconnect between developing the test, no matter how well you think you've designed the architecture, and actually implementation when you realize you need to tweak the architecture. * The tests became a liability--they frequently needed updating as the architecture changed * As coders, we think we can test code. But most of what I ended up needing tests for was UI behavior. What's the best way to make sure a method doesn't get called? To disable the button or combobox so the user doesn't do something prematurely! Writing test code for UI's is not the same thing as writing tests against code. Big fail in the TDD concept, in my opinion. * Effectively doubles the time it takes to put out a project. No, it doesn't save time. No, it doesn't necessarily make the code more robust. You can easily end up with more test code than actual application code. * Set up for complex projects is, well, complex. Setting up initial data, etc. * Without a mocking framework, TDD is sort of useless for anything but trivial tests. You need a mocking framework to spoof the DB connection, the communication channels, the UI, etc. So, ultimately, I came to the conclusion that it's a nice idea, it's a useful tool, but use it judiciously. Like anything else! Marc
My Blog
An Agile walk on the wild side with Relationship Oriented ProgrammingAs someone who started trying TDD last Feb but really hit it hard on a project a few months ago, here's my takeaway regarding some of the cons. UI testing is getting more and less of a problem. Frameworks like MVC are making it so that if things are written well there should be very little view logic in your controller code. I'm incredibly grateful to no longer have to see code like (if data = 37 then control.hide()) or something similar. On the other hand, so much logic is happening in Javascript now that unless you're using something like QUnit (and enforcing it among the teams) you're back to square one. I'd argue TDD does save time, but that time is manifested as time you didn't have to spend researching, finding, fixing, testing, and deploying a bug. We've just started TDD on a project and I've seen what happens when tests are run and I've seen the case where we've chased a bug only to be frustrated that had the developer who changed the feature run the tests (or if the automation had run it...different problem heh) we'd have saved a few hours. TDD certainly increases your dev time though, no question there. Speaking from a .NET perspective, with things like RhinoMocks and Moq, not having a mocking framework really shouldn't be an excuse. And if you're doing IoC you have Ninject, StructureMap, etc., so building apps in such a way that you can use a mocked db layer or a real one should also be fairly simple. My two cents.
-
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
-
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
Technically, yes, you'd have to provide test cases for everything that could go wrong, and that would indeed cost a lot of effort. A compromise would be to just provide one or a few cases of bad data, and only add more cases when you actually encounter a specific case that wasn't covered. It would prevent you from creating dozens of bad cases that in praxis never reeally happens. You'd still be able to run regression tests that way, i. e. when you fix a new bug, by always adding a test case for it you can make sure that the tests for already fixed bugs still pass. In the end it's you who must weigh the benefits of testing more against the effort it takes to produce these tests.
-
What is TTD actually? I never heard of it..
The general software design process looks roughly like this: 1. gather requirements 2. write use cases 3. implement them 4. write tests 5. test against the requirements In TDD it's more like 1. gather requirements 2. write test cases 3. implement them 4. write use cases 5. implement those 5.a) continually test the use case implementation using the already implemented tests Technically it shouldn't be all that different, but in praxis, tests are often written by the developers and tend to cover only the functionality that they have implemented, rather than the requirements that are supposed to be met. That only works if the use cases really fully cover the requirements, and the implementation really fully covers the use cases - and both are sometimes hard to verify. In TDD the test are written beforehand, the only information you can base them on are the requirements, so you're forced to implement that. Even if you lose information while writing and then implementing use cases, you'll catch that in testing. At least that is my understanding - you may want to check out wikipedia or other sources for a more in-depth explanation.
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
Wout hit it right on the head, IMHO. TDD's major value is in reduced cost of maintainability. If it's a ship it and forget it project, I've not found the overhead to be worthwhile. Conversely, if you are dealing with code you'll be enhancing, tweaking, and growing over months and years, the efficiency gains in pinpointing problematic code rapidly outweighs the overhead of writing the code.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
I recall someone on gamedev once stated he finds books unnecessary as he taught all(!) software solutions to himself without any help. You might agree that this is likely a limited view angle. Trying new things is rarely the fastest way forward in my experience, but it might give you new valuable perspectives, even on things you already knew.
-
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
Preface: I have a post earlier that makes a distinction between xUnit test frameworks, and the TDD process, so I won't repeat that info. They are two distinct parts that compliment each other nicely. One thing to keep in mind, is this all deals with "unit" testing. Which should be each distinct object, or global function that you create. However, it is possible to scale it up to integration and system level testing. As stated, it does not work well for UI testing. Now to your questions:
jasperp wrote:
do you apply TDD to data as well
Yes
jasperp wrote:
Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database?
Yes
jasperp wrote:
I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data.
These are actually 3 different parts of the app to consider. a) The source of the data does not matter to the object that is processing the data, b) it only matters that the data is input properly, therefore this will be the System-Under-Test (SUT). c) This only matters in the sense that it becomes the verification data.
jasperp wrote:
So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
This is the perfect scenario to use xUnit tests. You don't actually want to connect to a real-database when you are running your unit-tests. You want your tests to run quickly, and verify that your object is performing the proper actions. Generally this is done by creating stub objects to fill in for the databases, network connections, file access and so on. If you can isolate your objects with these unit-tests, then you create a much more flexible system with less dependencies. Look up blogs by Kent Beck and Michael Featherly. They have written some of the books that I have found very useful, and can provide more clarity that I can put in this forum entry.
All of my software is powered by a single Watt.
-
Wout hit it right on the head, IMHO. TDD's major value is in reduced cost of maintainability. If it's a ship it and forget it project, I've not found the overhead to be worthwhile. Conversely, if you are dealing with code you'll be enhancing, tweaking, and growing over months and years, the efficiency gains in pinpointing problematic code rapidly outweighs the overhead of writing the code.
If I ever have to again inherit code that I must enhance and maintain I would definitely use a TDD approach.
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
I like the TDD methodology. I dont have too much experience with many others related to unit-testing. TDD does not have to be followed to still have unit-tests. However, one of the other posters made a good point. When you write the tests up front, you are integrating the testing with thinking for design and implementation. When you write the tests as an after thought, it becomes mundane, and feels like an unnecessary chore. * The longer the code will be in use, the greater the benefit from building a test framework around the source. * Each time a defect is discovered, first write a test to detect the defect, then add the fix. If you maintain the tests as well as the code, you should never see the same defect twice. * It allows new developers to the project to understand the system faster because they are able to play in a sand-box with a safety net. You can change some of the code and see what it affects. Tests will fail. Then you inspect those tests and get some context. * When I jump into some complicated code that has no testing around it, I am very timid. I end up studying for sometimes weeks, then make a one line change still hoping that I have not introduced any side-effects. * I have my environment setup, so that I develop my objects in their own test suite, then I have the application itself. When I make changes to my object, I change them in the test suite. I am generally compiling and running the tests at least every 5 minutes. * The very first thing I do when I update my source for the project is run the unit tests. I will instantly know if anyone has checked in code that is broken before I start to work on my next set of changes. Hopefully that is a good starting list.
All of my software is powered by a single Watt.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Many people interchange Test Driven Design with automated unit tests. These are two different concepts, each having potential benefits and costs. In Test Driven Design, tests essentially define requirements and are supposed to only be written when specifically identified as a requirement. No software is written until the tests are written. As new requirements are communicated, new tests are written and new code is written or refactored. Unit testing can be done with any methodology. I have worked with people who adhere to Test Driven Design religiously. While I can appreciate the approach when you are working in a completely new domain where your business knowledge is very limited, when working in an environment where you have significant experience, the process slows you down. The word refactor becomes a four letter word $#@!. Unit testing can be an invaluable tool, especially when you have classes with complex business logic. We developed a calculation engine for a leasing company that involved very complex rules and the use of automated unit tests was invaluable as the engine took on new capabilities. I have also found that the use of unit testing forced the design to clean up interfaces between various classes. As has already been said. It's a tool. First get familiar with the tool. Then use it where appropriate.