Conference Video - Deep Stack – Tracer Bullets from ADC to Browser
A blank page can be very intimidating, even for a Test-driven developer. Where do we start? Write a test, right? Not always.
more...Course code | Kind | In a Word | Impressions | |
---|---|---|---|---|
A**-1 | like | Confidence that my code works | It makes sure that every line you write is tested | |
A**-1 | like | Confidence that my code works | While you progress, you can check that the basic functionality that you already programmed didn't break. | |
A**-1 | like | Confidence that my code works | I liked creating code increasing its complexity | |
A**-1 | like | Fast feedback | Makes you think deeper about coding a module | |
A**-1 | like | Find problems quickly | New possible errors not known befire testes. | |
A**-1 | like | Find problems quickly | I feels that it is much more complicate to enter a bug. | |
A**-1 | like | Find problems quickly | I like that you feel that what you are coding is more robust and bugless | |
A**-1 | like | Find problems quickly | I like that you can find more quickly the problems when you don´t know the good request from your code | |
A**-1 | like | Find problems quickly | This methodology forces you to firstly think on how to make it fail, and avoid "working" assumptions. Also the way of making the test pass quickly makes the code to keep simple. | |
A**-1 | like | Find problems quickly | I like to have a process to follow which should help to avoid making mistakes. | |
A**-1 | like | High test coverage | It forces you to write testable code | |
A**-1 | like | Minimal implementation | this is an good tool to verify the written code. | |
A**-1 | like | Structured approach | Things should be done step by step. | |
A**-1 | like | Structured approach | Thinking about the corner-cases before doing the implementation helps you reach a better implementation | |
A**-1 | like | Structured approach | It's a sistematic way of performing tests and it helps you to think first on the module API before program it. Also helps you to avoid future errors because tests must continue working. | |
A**-1 | like | Structured approach | I like the simplicity, the structured way of implementing the code. | |
A******-2 | like | After completing the implementation, I already had a set of tests that could be used to refactor code | ||
A******-2 | like | It makes you think carefully about the implementation details before doing any development. | ||
A******-2 | like | It forces you to take small, incremental steps in development. | ||
A******-2 | like | The really tight feedback loop. Also, the fact that it forces you to think a little more up front about the design of the interface of the component you're testing, and its testable behavior. | ||
A******-2 | like | I liked how the tests guided the development process -- it forced you to think about development before you wrote code. | ||
A******-2 | like | It forces you to write tests to begin with. It tends to get you thinking about failure cases, and how to trigger them. It 'should' result in code with fewer bugs, reducing churn down the road with the test team. Gives confidence that i won't break existing stuff, if i add/alter the codebase since i have a suite of tests already. | ||
A******-2 | like | Quick feedback on the current functionality you are working on. | ||
A******-2 | like | It drives you to break up a challenging problem into smaller chunks. | ||
A******-2 | like | If you break something in your existing code, you should know almost immediately what is breaking it and why. | ||
A******-2 | like | It helps the developer to pickup from where they left off last. | ||
A******-2 | like | The tests are generally short in length. | ||
B**-1 | like | Ahhummm | This first exercise ran smoothly | |
B**-1 | like | Concise | I like the idea of working on one problem at a time (small structured approach). | |
B**-1 | like | confidence | I like that I can be confident that new changes haven't broken functionality that has already been tested. | |
B**-1 | like | Convenient | It's nice being able to move on after a test knowing that the code is set up to work correctly. | |
B**-1 | like | Expansion | I like the different outlook on the coding. It creates a different way of thinking | |
B**-1 | like | good | a good test suite | |
B**-1 | like | modular | The coding and logic manipulations. Forces modular implementation | |
B**-1 | like | self-regulating | It makes the programming process rigorous and self-regulating. This prevent bugs from compounding and developing into massive bugs. | |
B**-1 | like | Systematic | Methodical approach | |
B**-1 | like | Systematic | A systematic approach | |
B**-1 | like | useful | TDD is very interesting approch to check my bugged code, it's look like easy for simple project such as circular buffer, but I'm not able to imagine how I'll implement it to more complex projects. | |
B**-1 | like | validation | validation will drive the implementation, not the other way around | |
B***-10 | like | You can start coding brainless and let the compiler/linker tells you you're an idiot :) It does allow you to see errors introduced along the way. | ||
B***-10 | like | As tests have to be written first, causes code to be more inherently testable. | ||
B***-10 | like | nothing interesting or to like so far | ||
B***-10 | like | Don't overthink. Focus on one thing at a time. Avoid implementation of things you know you will need in the future...wait until you need them. | ||
B***-10 | like | Nothing yet, because I am still learning | ||
B***-10 | like | The ability to actively do regression testing. | ||
B***-10 | like | I liked the concept of testing compilation errors as well as logic. A lot of times it is the things we take for granted that ends up throwing us for a loop. | ||
B***-10 | like | Being able to see when previous test fail when adding new functionality. | ||
B***-10 | like | I like that in the end there is test automation. | ||
B***-10 | like | The confidence felt when making a change. If it's not good, I'll know with a press of a button. | ||
B***-10 | like | I liked the test suite setup. It was easy and I could understand how to work towards a working code that began with testing. | ||
B***-10 | like | Don't have to visualize the entire problem all at once. | ||
B***-10 | like | working through the examples in a team | ||
B***-10 | like | Being able to see pieces of code are working right away | ||
B***-10 | like | It was a nice work flow of writing test, seeing them fail and then fix. Although, I did skip some iterations. | ||
B***-10 | like | The confidence in knowing the changes you did, were not in conflict to the previous legacy tests. | ||
B***-10 | like | Helps to keep implementations as simple as possible. | ||
B***-10 | like | When you are done coding the module. It has a test suite! Bugs are found VERY fast. | ||
B***-10 | like | Puts test on an equal footing with development. | ||
B***-10 | like | Small wins lead to bigger ones | ||
B***-10 | like | The methodical and incremental approach to code development. | ||
B***-11 | like | ease-of-use | Seems to be relative easy to use once we get the hang of it. | |
B***-11 | like | Efficient | A methodical process to build robust code and develop a based of test cases. | |
B***-11 | like | Incremental | Incremental development so always testing and find bugs early | |
B***-11 | like | love | Not really first impression, but TDD is a game-changer that makes code development easier, safer and more predictable. | |
B***-11 | like | minimalist | I like the idea of not building anything more than what you are currently testing. | |
B***-11 | like | Promising | Better opportunity to validate expected behavior and move on, while also identifying and testing edge cases. | |
B***-11 | like | Refactoring | Easy refactoring. I know that things haven't been broken by a change. | |
B***-11 | like | YAGNI | Helps with YAGNI because I can't write code if it doesn't have a test | |
B***-12 | like | Confidence | Having a large bank of tests is reassuring when making large changes. | |
B***-12 | like | confusing | it changes the mind of implementation. It seems that always in the status of trying to repairing the bugs. it makes me think more widely. | |
B***-12 | like | Efficiency | I think TDD is enable the development quickly and efficiency. | |
B***-12 | like | Everything | Everything. | |
B***-12 | like | feedback | I like the fast feedback loop. You're compiling and running very quickly after you start. | |
B***-12 | like | Feedback | Quickly able to verify changes didn't break previously working features. | |
B***-12 | like | feedback | quick feedback when a change broke something | |
B***-12 | like | future-proof | It can prevent working portions of the code from breaking | |
B***-12 | like | Gamification | It is satisfying to "solve" tests. | |
B***-12 | like | instant | Instant feedback if code is working | |
B***-12 | like | methodical | I like that the development process is very thorough, methodical, and structured. | |
B***-12 | like | quick | Quick feedback | |
B***-12 | like | quick | Quick feedback | |
B***-12 | like | robust | You can refactor/add code with less worry about breaking existing functionality | |
B***-13 | like | All the above. | It's fun to see the output of your changes right away in a very easy, simple-to-digest, form. | |
B***-13 | like | Confidence that my code works | Positive affirmation that was is expected is delivered. | |
B***-13 | like | Confidence that my code works | Made me confident to change my code | |
B***-13 | like | Confidence that my code works | The moment where we had to refactor to get circular looping working felt less stressful since I had the tests to confirm I did break anything that was already working. | |
B***-13 | like | Confidence that my code works | The unit tests make it easy to document the thought process of what is expected of the code under test. | |
B***-13 | like | Fast feedback | xxxx | |
B***-13 | like | Fast feedback | I have enjoyed the immediate feedback on code. This style does not allow you to make large changes without incrementally verifying each step. | |
B***-13 | like | Find problems quickly | Finding out that my code is buggy right away Helps keep me on task when I'm always just a few small changes away from getting something to work | |
B***-13 | like | Fun | Allows for multiple refactoring without limits | |
B***-13 | like | Minimal implementation | It was interesting, not having to figure out the entire data structure and interface first. Iterative. | |
B***-13 | like | Structured approach | Forces you to think about all the edge conditions. | |
B***-13 | like | Structured approach | Offers a structured method to developing software. | |
B***-13 | like | Structured approach | Let you build tests that you were confident in even if the implementation underneath was only half-cooked | |
B***-5 | like | like 1 | ||
B***-5 | like | like 2 | ||
B***-5 | like | the weather... | ||
B***-6 | like | Powerful way of checking code meets requirements | ||
B***-6 | like | The impression that the code is more "robust", that I can rely on the tests to catch my mistakes. | ||
B***-6 | like | Learned about an alternate way of testing your code faster. | ||
B***-6 | like | I like the way the number of tests continually grows so you will find out right away if you broke existing functionality while adding new functionality. | ||
B***-6 | like | It really provides a good mechanism for not writing buggy code. | ||
B***-6 | like | How it continually double checks the small details; so as the design grows, it challenges your initial assumptions. | ||
B***-6 | like | time to discovery of bugs, missing design features, early focus on exercising the client-side, early refactoring | ||
B***-6 | like | Only implementing code that has written tests keeps requirements from growing silently | ||
B***-6 | like | It seems like a very promising method to force myself into writing solid code from the first day of a project. | ||
B***-6 | like | Write tests before coding. This makes me think more logically while writing the code. | ||
B***-6 | like | The pace is surprisingly pleasant, since it makes you "rest" when you write tests, and it helps you focus on a specific functionality when you write the code. | ||
B***-6 | like | Someone else could work on the code and not cause collateral damage. | ||
B***-6 | like | I could work on this code six months from now and not cause collateral damage. | ||
B***-7 | like | Ease : I liked that the infrastructure was already set up. | ||
B***-7 | like | challenging: It's a new challenge | ||
B***-7 | like | easy: It was easy to get my head around the small, incremental additions to the functionality. | ||
B***-7 | like | Developing and testing in incremental steps | ||
B***-7 | like | functionality: It forced me to focus on improving functionality incrementally. You shouldnt add something unless you absolutely need it. | ||
B***-7 | like | suuport: It's like having someone constantly check your code for you | ||
B***-7 | like | Algorithmic: It provided a very algorithmic approach to setting up the skeleton of the code. | ||
B***-7 | like | Immediate: feedback | ||
B***-7 | like | Unafraid: It made putting together several necessary functions seem less daunting. | ||
B***-7 | like | BABY STEPS: - Effective bottom up approach to software development. - I like the idea of baby steps as opposed to nailing down all your ideas at once | ||
B***-7 | like | Proximity: I like how the corner cases are being tested while the code is being written. | ||
B***-7 | like | Tracking: I liked being able to easily track and see how modifying functions broke previous tests. | ||
B***-7 | like | Feedback : I liked that when a function was changed, the implications were immediately detected. | ||
B***-7 | like | Trust: I can ensure that every time I add new code, the tests will be able to detect a bug right away A different approach to developing code. | ||
B***-7 | like | test fail: I liked the idea of testing the inclusion of each added component, by making the inclusion of each added component fail first. There are times when I have written too much code at once, and have to later troubleshoot to find out I'm not using a portion of code that I think I am using. | ||
B***-7 | like | can follow simple steps; | ||
B***-7 | like | Fast: Fast feedback. | ||
B***-7 | like | Clean: The source code looks clean. | ||
B***-7 | like | TDD gives developer a mean to quickly interactively develop the test cases and the code without thinking too deeply in implementation. | ||
B***-7 | like | Easy/quick to start: guided by the TDD, develop the functions as test cases added. | ||
B***-7 | like | risk-free: refactoring | ||
B***-7 | like | challenge | ||
B***-8 | like | Very easy to track changes. | ||
B***-8 | like | testing gets stronger over time, builds confidence in the code | ||
B***-8 | like | iterative design can skip over some details, but create a test as a "reminder" | ||
B***-8 | like | All production code ends up being "known good" | ||
B***-8 | like | It made me think more carefully on what my code should be doing, and catching any bugs early-on. | ||
B***-8 | like | Test API first before implementation. That make me think about how another program use this code. | ||
B***-8 | like | I like that a developer can run the tests after a change to a code base to see if any tested functionality was broken. | ||
B***-8 | like | Very easy to find a bug introduced in later code development since the changes are incremental. | ||
B***-8 | like | Good gauge of progress towards the completion of a module. | ||
B***-9 | like | you know when things break. quickly | ||
B***-9 | like | It encourages quick feedback cycles and addictive green circles. | ||
B***-9 | like | Catches errors soon after you make them, makes them easier to find and fix. | ||
B***-9 | like | Seems straight forward in a simple real world example | ||
B***-9 | like | Short functions | ||
B***-9 | like | I like the control of small steps of progress. | ||
B***-9 | like | It encourages refactoring since your tests will help you find what you accidentally broke. | ||
B***-9 | like | made me think about how the thing I'm building is supposed to function before implementing it | ||
B***-9 | like | encourages object oriented structure and better separation of compilation units | ||
B***-9 | like | Knowing that I did not break anything. | ||
B***-9 | like | I like the immediate feedback that comes with TDD and the clean, modular code that the practice passively enforces. | ||
B***-9 | like | It forces you to build a test suite from the very beginning, so you can get 'free' regression as you move along implementing features. | ||
B**-1 | like | Thought provoking. | ||
B**-1 | like | I like that our work is deterministic. | ||
B**-1 | like | It is quick/easy to see when a change in one function broke something in another method. | ||
B**-1 | like | Design falls out while you write tests. | ||
B**-1 | like | Having a test bank that allows testing of refactored code. | ||
B**-1 | like | provide result from the output. | ||
B**-1 | like | working product after done | ||
B**-1 | like | less bug | ||
B**-1 | like | Getting quick feedback | ||
B**-1 | like | not as much to keep track of in my head by following this | ||
B**-1 | like | I enjoyed seeing how TDD may be used to incrementally create code. The guiding comments were extremely helpful. | ||
B**-1 | like | I like the constant feeling of getting "green" meaning the code that I have is working as best as I can tell at the moment. | ||
B**-1 | like | Like testing each incremental code change rather than waiting to tests multiple code changes all at once. | ||
B**-1 | like | Testing while development. Failing test, changing code to fix test, passing test. | ||
B**-1 | like | I like writing tests that ensure we don't break code with future changes. | ||
B**-1 | like | Old tests catch things when new code breaks them. | ||
B**-1 | like | Quick way to confirmation test will report error on failure. | ||
B**-1 | like | Simple and to the point | ||
B*-1 | like | Instant feedback. | ||
B*-1 | like | The dev only writes enough code to solve the problem. | ||
B*-1 | like | Was easy to isolate issues; there wasn't a giant change, then a giant search for the issue. | ||
B*-1 | like | I liked doing things in small chunks and feeling like I accomplished something every time a test passed. | ||
B*-1 | like | Catches errors right away | ||
B*-1 | like | It creates a mini iterative process at the function level which helps evaluate your work as you go. | ||
B*-1 | like | I like breaking down a problem into smaller chunks. I like seeing the immediate feedback of tests going green with each iteration. I like the fact that it accepts refactoring as a natural part of programming. | ||
B*-1 | like | It catches bug early | ||
B*-1 | like | Limits lot of manual tests | ||
B*-1 | like | Quick feedback on working or broken code w/ high confidence. | ||
B*-1 | like | ensure the correctness of the program since each iteration of refactoring the code need to pass all the unit tests. | ||
B*-1 | like | Found issues faster. Iterative process also found broken tests that used to work. | ||
B*-1 | like | I like the way functionality and unit tests are built up over time. Too often the unit tests are left until the end. | ||
B*-1 | like | The green and red colors emphasize we want to improve one small part at a time. | ||
B*-1 | like | writing the requirements as tests that drive my development | ||
B*-1 | like | Write the minimal code required to pass the test Provides you with a different perspective There are other good ideas out there | ||
B*-1 | like | It's fun to make the dots go green; it is more fun to write a test and get your code to pass it than write code and then feel hassled to write tests after. | ||
B*-1 | like | Fun. | ||
B*-1 | like | I like working in pairs because we often found each other's errors as we went. | ||
B*-1 | like | only focused on one problem at a time; added complexity as needed | ||
B*-1 | like | It catches a lot of bugs upfront. | ||
B*-1 | like | Nothing? | ||
B*-1 | like | makes you think in units | ||
B*-1 | like | |||
B***-1 | like | Efficiency | It shows you your errors quickly, and allows you to isolate the issue to a few lines of code. It allows you to build your code in small increments, which lends itself to refactoring. | |
B***-1 | like | encourage | I like the improved quality. | |
B***-1 | like | harness | I liked the harness driven approach. It is faster than debugging. | |
B***-1 | like | incremently | It allows to test and check if the test is correct. Then increment your test and do the process again and again. | |
B***-1 | like | like | Minimizing the number of changes between executions of the test which reduces the possible causes of the failures. | |
B***-1 | like | Method requirement | Testing first allowed me to understand what I wanted from the method before writing it (keeps the method scoped to doing the one thing). | |
B***-1 | like | Quick results | Quick feedback when there is a but in the code. | |
B***-1 | like | Sensible | The concept of driving development by testing makes a lot of sense. I'll definitely be using this approach in the future. | |
B***-1 | like | small testable code | It gives me the discipline to make small incremental changes to the code and ensure its quality instead of writing a large code and not know what defects I have introduced. | |
B***-1 | like | structured | It's structured, that helps to detect errors earlier. | |
B***-1 | like | test...test | forces you to test your implementation while you develop the interface for your code. | |
B***-1 | like | think | Makes you stop and think about how your implementation will work before you actually implement it | |
B***-1 | like | 1.Systematic creation of tests seems very intuitive. | ||
B***-1 | like | It makes you want to write more tests. | ||
B***-1 | like | All the tests that encapsulate the entire future code are already written for you | ||
B***-1 | like | Interesting exposure to something new. | ||
B***-1 | like | The steps were very logical to avoid adding bugs to your code. You try to never put yourself in a situation where you are relying on untested code for your testing. | ||
B***-1 | like | Rapid api consolidation. Plus rapid progress from working code to working code (after I stop digging the hole) | ||
B***-1 | like | It results in code that is inherently testable and probably structured better than otherwise. | ||
B***-1 | like | It's forcing direct thinking about a clean simple way to meet a requirement. | ||
B***-1 | like | I like how deliberate it feels. This adds more confidence to the correctness of each step and change you make. | ||
B***-1 | like | I like the simplicity of the coding and testing. | ||
B***-1 | like | I like the fact that testing is incorporated into the development process. | ||
B***-1 | like | If applied diligently it can ensure that your code is testable and provides confidence that it is operational. | ||
B***-1 | like | The natural progression that development follows. | ||
B***-1 | like | The process results in small tests. It results in complete code coverage. | ||
B***-1 | like | Test cases are roughly outlined before implementation; forces developer to keep tests in mind throughout implementation. | ||
B***-1 | like | I like the quick feedback, and that limited changes before a test limit what has to be examined for debugging. | ||
B***-1 | like | Raw, simple efficiency of forming very granular steps to achieve what may be a complex project. | ||
B***-1 | like | The hands-on demo was useful. | ||
B***-1 | like | Helps with interface design. | ||
B***-1 | like | I like the "fake it 'till you make it" strategy of starting with tests, fill implementation only to satisfy those tests, and iterating. | ||
B***-1 | like | The focus is kept on one thing at a time, e.g. fleshing out the IsEmpty interface and functionality first. | ||
B***-1 | like | it gives more of a sense of stability when the coding is complete | ||
B***-1 | like | Pair programming | ||
B***-1 | like | It broke the problem down in to simple steps there were easier to digest. It was easy to refactor code and verify that everything still worked. | ||
B***-1 | like | confidence that regressions aren't happening | ||
B***-1 | like | - I liked the confidence that the test suite gave me when making refactors | ||
B***-1 | like | I enjoyed the adversarial aspect of writing my code to pass the unit tests in a way that did not actually completely implement the functionality. It made me think much more about exactly what each test did and what tests are needed. | ||
B***-1 | like | Small incremental changes and knowing that nothing unexpected has broken elsewhere while making changes. Pair programming and the immediate code review feedback offered. | ||
B***-1 | like | Generates a lot of good test cases as the implementation evolves. Makes refactors/evolution much more straight-forward (even during the initial implementation). | ||
B***-1 | like | 1. Stripping the application down to its base functionality forced me to keep a steady, productive pace. If I'm not careful, I will code way too fast and get stuck on problems that shouldn't have existed in the first place. 2. Pair programming was fun | ||
B***-1 | like | Short functions with very low cyclomatic complexity and coupling. | ||
B***-1 | like | Self-documenting code. Comments not required. | ||
B***-1 | like | I really enjoy the emphasis on only implementing things that you need to, when you need to. Often times, we add things we'll think we need and they never end up being used or being relevant. | ||
B***-1 | like | rapid verification, with automatic regression testing as I proceed | ||
B***-1 | like | fast feedback simplicity of tests | ||
B***-1 | like | Exciting to see how the mesh of tests came together to create a net to catch new problems that may arise, given you don't want to fundamentally change some submodule elements. | ||
B***-1 | like | It utilizes my natural laziness to help me write cleaner code. The "you're not gonna need it" thought occurs to me more frequently when I have to write a test for some feature I want to add before I add the feature. | ||
B***-1 | like | Helps emphasize test-to-design considerations. | ||
B***-1 | like | I don't need to go back and write tests! | ||
B***-1 | like | I feel confident when refactoring code written using TDD. | ||
B***-1 | like | BLUE-1 | BLUE-1 Test Comment | |
B***-2 | like | definitions | It helped really define the class interface before actual implementation was required. | |
B***-2 | like | Finding defect early | Finding defect early. | |
B***-2 | like | Interfaces | Forces you to specify out your interfaces early (pre- actually implementing them) | |
B***-2 | like | process | Getting a demonstration of how it is applied from an expert. The pattern of fail compile, fail link, fail test, pass test. | |
B***-2 | like | safer | Feels safer to change code | |
B***-2 | like | simple | Clear, simple framework | |
B***-2 | like | simplicity | I like the iterative develop to get the smallest solution working. | |
B***-2 | like | Thorough | The emphasis on failing early and often.The incremental approach to building tests. | |
B***-2 | like | warm fuzzies | That your velocity increases as your body of written tests grows, and you get more warm fuzzies. | |
C*****-1 | like | quick series of rewards, like playing blackjack | ||
C*****-1 | like | Frequent feelings of success when getting a new test passing; gradually building a suite of test that guarantees your methods still work. | ||
C*****-1 | like | Being forced to slow down and think about verification of functionality earlier. | ||
C*****-1 | like | I like that it provides a methodical way for us to make concrete progress. | ||
C*****-1 | like | My coding partner was excellent. | ||
C*****-1 | like | Unit test development is a part of code development process | ||
C*****-1 | like | built a surprisingly robust test suite for fairly low effort | ||
C*****-1 | like | I liked that I can quickly see that an error happened, and what caused it. | ||
C*****-1 | like | I like that TDD makes me think about the correctness of the tests firsts as I develop the code and that the tests are implemented as the code is developed. | ||
C*****-1 | like | I've done some TDD before, but I enjoyed the explanation of the 'why' of taking things slow and why not to skip ahead. | ||
C*****-1 | like | The hands-on part. The lecture was good, but doing hands-on is how i learn. | ||
C*****-1 | like | I like that how this is making me think about the design. | ||
C*****-1 | like | I like the breakdown and the thought of taking a step at a time and getting the feedback | ||
C*****-2 | like | "secure" | I liked that everything is supposed to be and keep working regarding the continuous requirements on the way to MVP | |
C*****-2 | like | debugability | You find the bug shortly after the code is written. While its still fresh in your mind. You can refactor with some degree of safety. | |
C*****-2 | like | Found difficult bugs | The tests and the tool did discover things like memory-leaks and writing out of bounds, these are difficult to find problems. | |
C*****-2 | like | fulfilling | Seeing progressive improvement was great. Able to execute my code without it being part of a larger component | |
C*****-2 | like | Great! | I liked how methodical it is. Writing tests and watching them pass is fun. Making small changes is a great idea | |
C*****-2 | like | iterative | The iterative nature of TDD. For the most part, it allowed you to focus on smaller pieces of the code. | |
C*****-2 | like | iterative | Helps to ingrain iterative development into oneself. | |
C*****-2 | like | loop | I liked that the environment allowed for quickly running tests and seeing results. | |
C*****-2 | like | not as much overhead | The process did get easier as the implementation became more complete. | |
C*****-2 | like | nothing | nothing. | |
C*****-2 | like | show | I like having the tests to show me what's not working. | |
C*****-2 | like | simple | it dosent take a lot of effort to make your code pass | |
C*****-2 | like | tricking tests | The exercise we performed demonstrated the importance of writing test sets that can't be tricked into passing. | |
C*****-2 | like | unbiased | Testing is considered upfront before any code is written. | |
C*****-2 | like | validation | It is great seeing confirmation that the code you're writing is working as you're writing it. | |
C**-1 | like | accomplishment | gives you sense of accomplishment. | |
C**-1 | like | agile | The concept of devloping and testing in small increments, its like Agile, aka iterative waterfall :) | |
C**-1 | like | code overview | Force me to rethink what I have implemented. | |
C**-1 | like | Completeness | Disciplined way to make you think about the issues that your code has to address, step-by-step. As you build the tests that will validate the code. | |
C**-1 | like | deterministic | converts hidden test and debugging time into actual measurable (and very long) deterministic development/ testing time | |
C**-1 | like | effort | Forces you to think about developing in a different, initially less comfortable way. | |
C**-1 | like | enjoy | I like the exercise, I find it is a good way to put the theory in practise. It makes the concepts materialise and easier to remember. | |
C**-1 | like | Fast | Fast development cycle Immediate conformation that functions are working Test case implementation is not pushed to the end of implementation. | |
C**-1 | like | incremental | It's methodical, with only small changes made with each cycle | |
C**-1 | like | incremental | It breaks down the problem. Enforces incremental development. Ensure that new features do not break existing ones. | |
C**-1 | like | increments | Small increments are easier to manage | |
C**-1 | like | mistakes | Experiencing mistakes I do in coding, like wrong checking | |
C**-1 | like | peace of mind | Having confidence that my code is somewhat tested | |
C**-1 | like | positive | feels like you can make significant progress without completing much functionality | |
C**-1 | like | procrastination | it is OK to be a 'lazy' programmer, and procrastinate until you are forced to. | |
C**-1 | like | progressive | I liked that it was testing chronological building blocks. Building into larger more complete pieces of code. | |
C**-1 | like | refactoring | Helps with refactoring. | |
C**-1 | like | robustness | At then end of the process you have a working module and a test suite to ensure tha the module continues operate correctly as changes are made. | |
C**-1 | like | Simplicity | It was easy to get the intended logic step by step. It was not that easy to introduce bugs, as we could see it fail then and there. | |
C**-1 | like | straightforward | It is a more straightforward/mechanic method to develop | |
C**-1 | like | Testability | Makes you think about development step by step and each part is proven with a new test. | |
C**-1 | like | tests | Tests are present for functionality. | |
C***-1 | like | - I like that it will forever more be tested without any manual process by myself. - I like the methodical way of building the test and code. | ||
C***-1 | like | It helps define the interface as you create the test code Step by step process of creating code | ||
C***-1 | like | The endorphin rush of getting things passing again. | ||
C***-1 | like | The continuous "handshake" of fail change pass change <repeat>..." gives me confidence in my process and my result. | ||
C***-1 | like | It really keeps me focused, and helps me pickup where I lost my focus. As an engineer, I rarely get to sit and work through an entire solution without interruption. | ||
C***-1 | like | Not as difficult as I thought it would be Encourages optimizing the number of input parameters to each function | ||
C***-1 | like | It's fun. It keeps you focused. It discovers bugs in functions that you created a lot earlier. | ||
C***-1 | like | It was systematic. You can verify as you go along. (You have expectations and code to tell you if your expectation was met.) | ||
C***-1 | like | Small, simple steps Past tests help check future development Interface gets a trial run | ||
C***-1 | like | I like the repetitive sequencing of test, code, test code. I like that every test is run every time ensuring that I didn't break some previous thing. | ||
C***-1 | like | step by step helped force me through the correct process | ||
C***-1 | like | Prevent bugs Catch bugs as you develop production code Help to design and redesign your software | ||
C***-1 | like | small tasks | ||
C***-1 | like | build on prior success | ||
C****-15 | like | Complete COde coverage All +ve, -ve testcases, all scenarios | ||
C****-15 | like | moves issues to the left to discover them sooner | ||
C****-15 | like | The tests cover all the requirements. | ||
C****-15 | like | I like the concept of TDD so far. The concept is pretty straight forward | ||
C****-15 | like | Reliably develop features and deploy to production, fewer defects in tests. | ||
C****-15 | like | It's real-time testing | ||
C****-15 | like | The simplicity with which the course started. Not too much info at the start.And doing some exercise/lab with first hour itself. | ||
C****-15 | like | x | ||
C****-19 | like | short time to get test results | ||
C****-19 | like | 'Forces' writing of unit tests | ||
C****-19 | like | The tests do drive me writing code correctly. | ||
C****-19 | like | It was easy to build comprehensive testing from the multiple small blocks | ||
C****-19 | like | Incrementally building up working functionality | ||
C****-19 | like | Simplicity. | ||
C****-19 | like | Fast build/run/test result cycle is brilliant | ||
C****-19 | like | More transparent what was being tested, as we were doing things incrementally A side-benefit of this was that it seemed to make pair programming easier. | ||
C****-19 | like | Not adding unnecessary code (not trying to future proof things) Each area of code is tested, i.e. avoiding having un-testable code. As your design evolves, there is enough requirements-as-tests present to see if we have broken something | ||
C****-19 | like | first session was good. | ||
C****-19 | like | Building a regression suite of tests as we add to the implementation means that we check we don't break anything we've implemented earlier. | ||
C****-19 | like | Fast feedback of what works / does not work in a small and specific part of the code | ||
C****-19 | like | Not having to think too far ahead. | ||
C****-19 | like | Having a suite of tests gives me the confidence to refactor the code without breaking anything. | ||
C****-19 | like | Easy to test my code step by step | ||
C****-19 | like | It actually creates easy to understand tests | ||
C****-19 | like | building the trust/confidence that you can change the code | ||
C****-19 | like | I can build up the design incrementally, I don't have to design it all and think of everything up front e.g. start with simple static allocation first before moving to dynamic allocation. | ||
C****-19 | like | Interactive session. | ||
C****-19 | like | Easy to see what the test was trying to test | ||
C****-19 | like | small changes between test runs, so it's easy to spot what went wrong if tests fail | ||
C****-21 | like | Helps to write clean code | ||
C****-21 | like | Create code step by step | ||
C****-21 | like | no need to worry about regressions. If any previously functionality fails it will immediately catch. | ||
C****-21 | like | I'm not sure I liked anything yet - It's disorienting and difficult to resist just writing code whenever a bit of a problem arose. I'm still giving it a chance though. | ||
C****-21 | like | It is a very thorough method and does not leave much room for error. Pretty much all of the bugs are coming from you and how you wrote your code, and the TDD method calls for you to only write what is necessary, giving you less room for mistakes. | ||
C****-21 | like | 1. It adds assurance that your code is behaving as expected. 2. It is methodical and helps tightens design. | ||
C****-22 | like | The fast turn around between coding and getting results back | ||
C****-22 | like | the coding environment is pretty good | ||
C****-22 | like | Each mistake we made was obvious immediately (except when we made too big a jump and started using printf!) | ||
C****-22 | like | - teacher is clear and approachable - course feels useful - The test environment is easy to use and useful | ||
C****-22 | like | I like my changes are tested on the go. Also the changes are tested in an iterative manner. | ||
C****-22 | like | A) The factor I liked about is development being driven by test focus. Earlier days, we were laying out the foundation of the development code first and then write and finally we do testing. But with TDD, the focus is shifted to how to test before start developing code. | ||
C****-22 | like | It catches memory leak... | ||
C****-22 | like | easy to have good test coverage. | ||
C****-22 | like | docuement the requirement, easy to maintain in the future. | ||
C****-22 | like | good for refactoring | ||
C****-22 | like | It helps practice pace of development, exercise the ability of use as small as possible steps, and choose appropriate pace in case by case. | ||
C****-22 | like | It finds bug by failing previous test scenarios/cases as we proceeds... | ||
C****-23 | like | Refactoring is fun when you have tests | ||
C****-23 | like | Simplicity of each change. | ||
C****-23 | like | Enables me to think about the logical steps of what I want to do and less about the code. | ||
C****-23 | like | Naturally leads to a clean design | ||
C****-23 | like | forces you to divide problem into subproblems | ||
C****-23 | like | Short feedback cycles | ||
C****-23 | like | Gets an instant satisfaction every time a small test passes | ||
C****-23 | like | Easy to fix issues early | ||
C****-23 | like | Easy to stay focused on the task at hand. When you are finished coding, the tests are there :) | ||
C****-23 | like | Breaks down complex problems to small and easy tasks | ||
C****-23 | like | Discovering the interface by writing tests | ||
C****-23 | like | You have put more effort into making a plan before you start to program, and when the plan is made, you have a receipt to follow | ||
C****-23 | like | The TDD framework decomposes a larger problem into small sub-problems which are solved separately. | ||
C****-23 | like | Even though the complete task to solve is complex, solving the small incremental tasks becomes quite trivial. | ||
C****-23 | like | Make sure you have good test coverage before you start refactoring the code | ||
C****-23 | like | It gets you started coding sooner (and safer), don't overthink | ||
C****-23 | like | Avoids analysis paralysis | ||
C****-23 | like | Fast feedback if code refactoring or new features breaks old functionality | ||
C****-23 | like | Helps you both document and create a simple API | ||
C****-23 | like | Easy to get started and feel productive | ||
C****-23 | like | Old tests detects failures introduced by new code and refactoring | ||
C****-23 | like | Helps with documentation | ||
C****-23 | like | Trustworthy tests eases and encourages refactoring | ||
C****-23 | like | Natural way to develop the API. | ||
C****-24 | like | Letting tests drive the development is an interesting philosophy. | ||
C****-24 | like | - Thinking about all possible scenarios and listing them down would help to figure out what are the areas to be covered in code so that we can test those incrementally and can try to write bug free code as much as we can | ||
C****-24 | like | Each small and incremental addition to the code is tested, before building on the top. | ||
C****-24 | like | First of all, it was something new that I have never tried before. I have always had the mindset of writing the code first before even thinking about how to unit test. So usually my approach is: 1. Write Code 2. Write Blank Unit Test to ensure that my newly added function (Most of the time) is called or executed. 3. Got back and refactor code so that it is more testable. But writing the skeleton unit test is definitely something new that I have not done before and I am willing to give it a try where applicable in my development from now on. | ||
C****-24 | like | seems very logical way of developing software. | ||
C****-25 | like | All the above. | Instant feedback with checks for memory leaks enabled. | |
C****-25 | like | Confidence that my code works | Thinking about production code incrementally | |
C****-25 | like | Confidence that my code works | The functions you write might have surprising behavior and the test helps to identify it | |
C****-25 | like | Fast feedback | Nice modular work. | |
C****-25 | like | Fast feedback | Very fast feedback loop code->testing | |
C****-25 | like | Fast feedback | simple and quite straight forward | |
C****-25 | like | Fast feedback | it forces us to think about every step of code development | |
C****-25 | like | Fast feedback | Writing code incrementally; it made identifying errors easier. | |
C****-25 | like | Find problems quickly | Incrementally driving code with tests helps to find issues quickly. | |
C****-25 | like | Find problems quickly | Idea of writing test before production code is really effective in pointing to code that can cause the failure. Makes the code coverage 100% automatically. helps in keeping design logic simple | |
C****-25 | like | Fun | Its very fun | |
C****-25 | like | Fun | We get to write code, that's small fun and easy | |
C****-25 | like | High test coverage | Sure not to develop unused code | |
C****-25 | like | High test coverage | Trying out a different development style than what I am used to. | |
C****-25 | like | Minimal implementation | forces you to get to the minimum complexity to meet requirements (expressed by tests) | |
C****-25 | like | Structured approach | Code driven by interface | |
C****-25 | like | Structured approach | it makes clearer the requirements. | |
C****-25 | like | Structured approach | I like how it brings into the dev process a formal and compiled definition of requirements. This is quite nice, because allows you to develop a minimal amount of code that fulfill the requirements. | |
C****-25 | like | Structured approach | It makes easier defining better signature (good for sharing) | |
C****-25 | like | Structured approach | The constant reminding of precise definition of what the functionality is supposed to do. | |
C****-25 | like | Structured approach | I need to think about few things at one given moment | |
C****-25 | like | Structured approach | Clear method | |
C****-25 | like | Structured approach | TDD makes development & unit testing well structured. It makes easy to see what's tested and what's not. | |
C**-1 | like | All the above. | Hands on exercise is useful | |
C**-1 | like | All the above. | I like the fact that we need to write enough code to just pass a failing test. And along the way tool does find overshooting (writing extra code than required for passing a test) based on coverage. | |
C**-1 | like | All the above. | Iteratively and incrementally the solution evolves. | |
C**-1 | like | Confidence that my code works | I like that TDD encourages breaking up a problem into very small steps that makes it easier to come up with a resilient solution. | |
C**-1 | like | Fast feedback | small steps you are covering you code so when adding new functionality you know very quick if you are breaking existing behavior. it is easy to go back to state where all your test are passing | |
C**-1 | like | Find problems quickly | Didn't have to setup or go through that. Nice UI and easy to start understanding TDD with hands on experience | |
C**-1 | like | Minimal implementation | Less load on the brain by tackling one small step at a time. Less mistake working with small steps | |
C**-1 | like | Structured approach | It's easier to break down the problem into smaller pieces if there is already a test describing what the code should do. | |
C**-1 | like | Structured approach | Iterative and incremental with tests baked in feels good. Don't need to race too ahead of time. | |
C**-1 | like | Forces creation of tests that can be used for regression testing when code is updated. | ||
C**-1 | like | Instance feedback on what went wrong | ||
C**-1 | like | Focus on coding :-) | ||
C**-1 | like | The ability to catch a mistake early on in the coding process. | ||
C**-1 | like | You find errors quickly | ||
C**-1 | like | the quality of code will be much better | ||
C**-1 | like | Ease of writing code, not thinking too much about all the corner cases at the first place | ||
C**-1 | like | Enforces thinking of testing and corner cases during development. | ||
C**-1 | like | - The process builds functionality from the API (bare-bones) to filling in details. - Tests make refactoring easy to validate. - The tests provide some level of 'documenting' expected behavior. | ||
C**-1 | like | helps in finding the mistake at an early stage | ||
C**-1 | like | Very meticulous and try to test every single line of code! Hence if some other engineer modify the code it would be easy to find if they breaek it. | ||
C**-1 | like | Makes you develop in much smaller phases. | ||
C**-1 | like | Incremental development with testing Don't need to focus on the detail right from the start Plus like the fact that the testing is done at compile time rather than a post step | ||
C**-1 | like | Encourages you to write the bare minimum code required to fulfil the requirements | ||
C**-2 | like | Steps were small and at each stage there was confidence that the functionality so far was a intended | ||
C**-2 | like | I like the iterative approach to implementation | ||
C**-2 | like | * Empowered to refactor code as we go, as we have testcases as we go. * fast turnaround of bugfixing. | ||
C**-2 | like | The simplicity of the incremental approach, keeping the changes small. | ||
C**-2 | like | Pure Discipline. Confidence that if i write code this way I will have to deal less with customer or last minute pressures to fix bugs. | ||
C**-2 | like | It's a methodical approach to development and test | ||
C**-2 | like | I like that the regression testing capability is built in | ||
C**-2 | like | Adds an extra level of thought process to dev | ||
C**-2 | like | We are testing every line of code not all together but as we write the code. It gives more confidence in unit/integration testing. | ||
C**-2 | like | It ensures that we test the code, find and fix the bugs as soon as possible therefore reducing the debugging effort and improve the quality | ||
C**-2 | like | The ability to have a test base for sanity checks | ||
C**-2 | like | test is built it and therefore budgeted in full! | ||
C**-2 | like | It seems to bring more structured/safer way of development | ||
C**-2 | like | breaks the problem down in to small chunks | ||
C**-2 | like | Practical | ||
C**-2 | like | Constructive and Structured | ||
C**-3 | like | Feeling of security. Immediate feedback. | ||
C**-3 | like | quick feedback on broken previously working behavior. | ||
C**-3 | like | Natural development of both functionality and tests for functionality hand in hand. Don't need to test and implement functionality that is not required. Tests remain available to support changes in implementation later. | ||
C**-3 | like | small steps - instant feedback | ||
C**-3 | like | I like the idea of not writing any code unless it is to make a test pass. | ||
C**-3 | like | It seems extremely thorough | ||
C**-3 | like | Development of test cases goes hand in hand with code (slightly pre-empting). Makes you define expected behaviour up front. | ||
C**-3 | like | 1) follows good practice: think about APIs, then implementation. 2) Additionally (new): binds a contract on the behaviour and rigour of those APIs 3) Possibly: means you do not over-implement the solution; beyond the requirements. | ||
C**-3 | like | Testing follows incremental code development from very start. | ||
C**-3 | like | Ability to know that changes and refactoring has not broken existing code at the time of development. Logical process | ||
C**-3 | like | - You know that if you are testing successfully, is working, and you will know when it stops doing that. Immediately. | ||
C**-3 | like | Small building blocks, re-use | ||
C**-3 | like | |||
C**-3 | like | - It allows you to focus on your task at hand, without worrying about what you did, because if you break it, you will know. | ||
C**-3 | like | Rigorous - all code in by definition "tested" - within the definition of the test case behaviors. | ||
C**-3 | like | It's fun. Helps to refine requirements More agile Better control over what do you code | ||
C***-1 | like | Quick feedback | ||
C***-1 | like | 1. finding bugs as we go 2. repeatable | ||
C***-1 | like | Not much at all. | ||
C***-1 | like | Its hands on Well organized steps Properly commented | ||
C***-1 | like | Good for future regression testing. | ||
C***-1 | like | incrementally adding checks it is good and some time not good. | ||
C***-1 | like | Writing and testing code incrementally | ||
C***-1 | like | Like seeing the unit tests pass and knowing the code did not regress. | ||
C***-1 | like | Helps in writing fully functional and bug free code . promotes thinking incrementally (one step at a time) which would result in less chance of errors. | ||
C***-1 | like | Taking small steps. | ||
C***-1 | like | Making the code to fail first and fix the issue | ||
C***-1 | like | Easy to test an API by inputting a lot of different parameter values. This would increase test coverage to avoid untested corner cases. | ||
C***-1 | like | "inherent" building of test oracles. | ||
C***-2 | like | Instantly knowing bugs. | ||
C***-2 | like | Step by step development | ||
C***-2 | like | Fast feedback | ||
C***-2 | like | 1. Quickly able to run code. 2. Environment conducive to quickly running tests | ||
C***-2 | like | Helps to maintain code quality | ||
C***-2 | like | TEST AND VERIFY CODE WHILE DEVELOPING. | ||
C***-2 | like | Step by Step tested code development More sad path based development which leads to happy path | ||
C***-2 | like | Incremental , instant gratification | ||
C***-2 | like | TDD lets me make sure that all my assumptions about the program I am writing are tested and correct. | ||
C***-2 | like | Can refactor with confidence | ||
C***-2 | like | Adding more granularity to the implementation. Adding granularity one step at a time. | ||
C***-2 | like | A test is intended to verify a requirement. Hence it verifies requirements. But the focus should be on requirements not tests. | ||
C***-2 | like | It is good. It allows you to think incrementally and involves developing something that is absolutely necessary. The chances of having useless stuff is less. | ||
C***-2 | like | I always heard a lot about unit test but never had first hand experience in developing unit test cases. Thanks to TDD. I am likin' it.... | ||
C***-2 | like | Creates safety net for refactoring and defect fixes. | ||
C***-1 | like | feedback | ||
D**-2 | like | Clear sequence of events for testing your softwaree | ||
D**-2 | like | Tests are written prior to function. When the code changes the tests already cover it. | ||
D**-2 | like | The speed of feedback | ||
D**-2 | like | The control over accuracy | ||
D**-2 | like | it helps to scope the task/implementation into smaller pieces and helps to confirm/test these parts right away | ||
D**-2 | like | Code will be thoroughly tested. | ||
D****-2 | like | Confidence | I feel more confident that my software is fully functional when I have a suite of tests that pass. | |
D****-2 | like | confidence | refactoring with confidence from known working code and test == good | |
D****-2 | like | FixFast | I like the short time between failure through diagnosis to fix. | |
D****-2 | like | focus | Helps frame the design by forcing to focus on one detail at a time. | |
D****-2 | like | incremental | small incremental progress in the right direction == good | |
D****-2 | like | Oversight | TDD help prevent creating undetected bugs in existing code when making modifications or refactoring. | |
D****-2 | like | Safety net | I like the safety it produces in a continually evolving code base. Ensuring future changes don't break pre-existing code. | |
D****-2 | like | short failures | That there are only short intervals of being in a state of not-working. | |
D****-2 | like | simple | I liked the incremental approach. | |
D****-2 | like | upfront | It forces you to flush out your interface and requirements as you write code without leaving the testing to the end. | |
D****-2 | like | usefull | It catches design problems and logical errors early before they become baked into the code | |
E**-1 | like | The atomicity of the implementation and that we straight see PASS FAIL cases | ||
E**-1 | like | after this process we have testable code. we don't need to write tests expost which would bring some bad suprizes | ||
E**-1 | like | Pair programming was fun and prevented lots of issues. | ||
E**-1 | like | testing one thing at a time | ||
E**-1 | like | Having a set of tests gives confidence that if we break the code we know it. | ||
E**-1 | like | Restart a test after rework, to check if we don't have broken something | ||
E**-1 | like | The fact to do the minimum possible to make the test pass | ||
E**-1 | like | helps to think about interface during implementaiton | ||
E**-1 | like | Be confident when we change something in the code | ||
E**-1 | like | I like that it complains immediately about mistakes. | ||
E**-1 | like | finding the errors faster and be sure that everything works | ||
E**-1 | like | designing the API as needed during test development | ||
E**-1 | like | The interaction between the tests and the real code. | ||
E**-1 | like | this programming flow force the engineer to minimize implemented features. | ||
E**-1 | like | The creation of a complex module is broken down into simple steps. | ||
E**-1 | like | Just write enough code to pass the test and no more | ||
E**-1 | like | Writing the tests was almost as fun as writing the code. But we know that with mocking it's a different story :-) | ||
F**-1 | like | amazing | Help me to have a mindset on how to test code during development | |
F**-1 | like | average | Make me think more carefully during the coding process. But it takes time to get familiar with. | |
F**-1 | like | careful | It helps me think more careful about my code | |
F**-1 | like | Easier | Just easier to debug and check my function. It helps me to be carefully to write code. | |
F**-1 | like | Fast feedback loop | - Help break down the development process into smaller steps - Immediately test the code that i write. Fast feedback. | |
F**-1 | like | Fast feedback loop | - Help break down the development process into smaller steps - Immediately test the code that i write. Fast feedback. | |
F**-1 | like | great | I could apply TDD for unit test of embedded firmware such as PIC, AVR, STM32 and run these unit-test on real devices with TDD | |
F**-1 | like | Interesting | TDD can help us develop/test software while developing. It can slow at start but wonderful when complete. | |
F**-1 | like | Strong | Very simple. Easy for understand | |
F**-1 | like | think corner cases | We can think about corner cases before writing code | |
F**-1 | like | thoughful | It can help me to think carefully most of the cases that the system can have before doing the implementation so we can have a draft structure of the system before writing code. | |
F**-1 | like | useful | That help me make sure that logic is still corret after modifying the code. And maybe it save my time to debug later | |
F**-1 | like | wonderfull | I like the way to step by step implement a complex feature with test case for each step. | |
F**-1 | like | workflow | The course will teach people how to perform unit test, integrated test, system test. | |
F**-1 | like | Wow | Should think about the system before start writing code. write and test continuously. | |
H*-1 | like | It is much easier to find my mistakes when I've only changed a few lines and/or only made the changes minutes ago. | ||
H*-1 | like | Encourages a logical, iterative development process. | ||
H*-1 | like | Iterative process that makes you really think about what you are implementing | ||
H*-1 | like | Very quick development cycle (write, compile, test) | ||
H*-1 | like | Simple to create unit tests to validate API and module behavior | ||
H*-1 | like | can find the mistake immediately and correct it before further development. | ||
H*-1 | like | I liked that the iterative process made it easier to find simple bugs early on. | ||
H*-1 | like | As I made changes to the production code, I was more confident than usual that I had not broken anything. | ||
H*-1 | like | regression testing | ||
H*-1 | like | quick feedback | ||
H*-1 | like | It gives a continual sense of progression | ||
H*-1 | like | After the investment of creating the tests - if the motivation for the tests is still valid - then having the many test cases increases the developer's confidence that the tested code is working correctly. | ||
H*-1 | like | The approach is pretty systematic, but does take some effort to keep to the approach. | ||
H*-1 | like | Simple principles (create test to fail, create code to pass test) | ||
H*-1 | like | I liked having the ability to quickly verify my logic | ||
H*-1 | like | I like the structured approach to building tests and incrementally adding functionality. | ||
H*-1 | like | If you can think of a test case, you can be sure that your code handles that case. | ||
H*-1 | like | I can start making progress without having thought through the entire design first. | ||
H***-1 | like | Fun, safe, and logical | ||
H***-1 | like | The instructor is AWESOME ! | ||
H***-1 | like | I like the relaxed and conversational tone of the training. | ||
H***-1 | like | Seems to be a good platform for testing with quick feedback | ||
H***-1 | like | What I like about TDD is the fact that it keeps us from creating unexpected behavior in the existing code. The tests help us enforce our requirements. | ||
H***-1 | like | safety net, systematic process | ||
H***-1 | like | I like pair programming. I especially like that I am learning a bit of c whilst sharing tdd. | ||
H***-1 | like | Simple, always move in right direction | ||
H***-1 | like | Forces you to think about what you are about to code and go through a logical progression. Less shot gunning. | ||
H***-1 | like | Its a different approach to writing code one small step at a time | ||
H***-1 | like | Hands on experience. | ||
H***-1 | like | Having confidence in the code | ||
H***-1 | like | Learning about what TDD is. | ||
H***-1 | like | Tool Cyber-dojo is so cool. Simultaneous coding and debugging is very good feature. | ||
H***-1 | like | Good way of writing bug free code | ||
J***-1 | like | Confidence that my code works | Greater confidence that my code works as expected. | |
J***-1 | like | Confidence that my code works | Provides immediate indication if your tests are being passed or if you broke a previous test. | |
J***-1 | like | Confidence that my code works | Minimize future issues. | |
J***-1 | like | Fast feedback | I liked how quick the feedback was for "Your implementation was wrong". | |
J***-1 | like | Fast feedback | I know immediately if there are issues | |
J***-1 | like | Fast feedback | I have a safety net when refactoring my code. I feel like I can get away from the classic embedded strategy of "it works, don't touch it". | |
J***-1 | like | Fast feedback | This is me | |
J***-1 | like | Fast feedback | I know immediately if there are issues | |
J***-1 | like | Fast feedback | See errors very soon after writing the code | |
J***-1 | like | Fast feedback | I liked the feedback in the process. It's always nice getting a green bubble. | |
J***-1 | like | Fast feedback | trest like | |
J***-1 | like | Fun | It feels silly to build the interface to just return 10 to force a passing test, knowing it'll break later but it's "good enough" right now. https://dilbert.com/strip/2001-10-25 | |
J***-1 | like | High test coverage | When running a newer test, I have confidence that I did not break an early design element | |
J***-1 | like | High test coverage | Forces you to think through and test the expected behavior at each step. | |
J***-1 | like | Minimal implementation | Helps with coding only what is needed and not more than that. | |
J***-1 | like | Minimal implementation | I liked the incremental build and test style. It keeps you focused on not tackling too much of the problem at once, which limits how complicated the tests are. | |
J***-1 | like | Other. | You develop a test suite for your code as you write the code. This has immense value. | |
J***-1 | like | Structured approach | I like how sequential it is and how it leads you through a prescribed process. | |
J***-1 | like | Structured approach | I appreciate the self-directed flow using comments as a "discussion" and the #def as a stop point. | |
J***-1 | like | Structured approach | Starting point is relatively simple | |
J***-1 | like | Structured approach | I liked that the exercises are small and manageable and drive the point home. | |
J***-1 | like | Structured approach | I like the hands on experience. Putting theory into practice helps reinforce the concepts | |
L*-4 | like | automated | Get automated test results for changed code | |
L*-4 | like | avoid bugs | I can reduce the chance of creating bugs. | |
L*-4 | like | avoid bugs | I can reduce the chance of creating bugs. | |
L*-4 | like | Basic | It reminds me "Back to Basic" | |
L*-4 | like | coding | I like change signal red or yellow to green (coding with test) | |
L*-4 | like | concentration | I can focus on each test step when writing codes. | |
L*-4 | like | error proof? | avoid chance to make mistake, errors | |
L*-4 | like | Feedback | responsive , feedback | |
L*-4 | like | feel safe | It's good to get me out of other related work and make me focus on one thing. As many test as i made, i feel safer for coding. | |
L*-4 | like | FUN | I felt testing and debugging was fun. Before taking this class, I really didn't like debug my code. | |
L*-4 | like | immediatly | check error case & handle it immediately. | |
L*-4 | like | in progressive | I liked that I can make the code in progressive from zero to hero. | |
L*-4 | like | makeing test code | I like making test code. it's a effective experience. | |
L*-4 | like | passes | I liked making code to pass the test, even though the test was simple. | |
L*-4 | like | prevent | Before I write code, I had to make test code for test it, and it will be very helpful when I modify my code. | |
L*-4 | like | proof | I can get each line of code tested. | |
L*-4 | like | Safe | While developing code with TDD by step by step, my code became better and I don't have to worry about the function that wrote before. | |
L*-4 | like | safe code | I got the feeling of building up the code. | |
L*-4 | like | Satisfaction | TDD makes me feel some satisfaction and progress. | |
L*-4 | like | separated | Complex implementations can be simply separated. | |
L*-4 | like | Stable | If test code gets well made, it looks we can make really stable S/W at the first time. | |
L*-4 | like | step by step | I can develop step by step more logically. | |
L*-4 | like | test first | I was impressed about starting with test codes and then implementing. | |
L*-4 | like | test like develop | Test also looks developing by making goot test code | |
M***-1 | like | architecture | Test driven architecture: The architecture of your code becomes testable and arguably better | |
M***-1 | like | collaboration | collaboration and support | |
M***-1 | like | Correction | Checks all the input conditions for the functions. | |
M***-1 | like | coverage | Easy way to get full functional 'coverage' | |
M***-1 | like | coverage | All possible situations are tested | |
M***-1 | like | Function | it seems to force you to really think about the function and responsibilities of parts of the code | |
M***-1 | like | requirements | I like that you can map requirements to code more easily. | |
M***-1 | like | Simplicity | 1 Thing at a time | |
M***-1 | like | Simplicity | forced to focus on one thing at a time | |
M***-1 | like | small | I like that it forces you to implement the code step by step, with small increments. | |
M***-1 | like | small step | software problem are divided is many smaller problem that are more easier to fix. | |
M***-1 | like | small steps | its breaking up development into small steps | |
M***-1 | like | structured | It forces you to create the API functions early in the process | |
M***-1 | like | way to go | helps to make code more robust | |
M*****-8 | like | Helps change mindset towards developing just what's required, rather than what you think might be required sometime in the future. | ||
M*****-8 | like | Keeps changes simple so therefore less to go wrong | ||
M*****-8 | like | Forces you to think about the testing at the same time or early in the design/code process | ||
M*****-8 | like | decreases the probability of making a mistake | ||
M*****-8 | like | TDD helps us to build a well tested environment | ||
M*****-8 | like | Iterative development/test small steps Build up functionality outside(API)/in | ||
M*****-8 | like | Ability to quickly detect failures in code previously believed 'to be good'. | ||
M*****-8 | like | Thinking about the testing stimulates thought about the code design. I like the gradual addition of functionality | ||
M*****-8 | like | I like the idea of doing the test at the same time as the coding, it helps to think and create test for the corner cases that could be missed when testing after months of developing. | ||
M*****-8 | like | - when you finish your development you have your test | ||
M*****-8 | like | the approach done step by step | ||
M*****-8 | like | Wide test coverage which could cover all corner cases. | ||
M*****-8 | like | The incremental approach | ||
M*****-8 | like | It is very different from what we normally code programs. We used to do full implementation first and try to avoid bugs as much as possible. Now, we need to think tests first; do not care about bugs. We catch bugs while testing. This may be a better way to program. | ||
M*****-8 | like | Incremental debugging routine, this helps peoples to create a complete/complex test environment using step-by-step procedure (keep it easy) | ||
M*****-8 | like | The methodical approach and the possibility of monitoring of function developed and the test case related. | ||
M*****-8 | like | catches things earlier | ||
N**-2 | like | The structured approach | ||
N**-2 | like | I like the stepwise approach. It gives you a sense of control over your code. | ||
N**-2 | like | The feedback is instant and apparent | ||
N**-2 | like | Takes one problem at a time | ||
N**-2 | like | Forces you to think about testability up-front. | ||
N**-2 | like | I liked that TDD gives me feedback while I am developing. | ||
N**-2 | like | The insurance against silly mistakes. | ||
N**-2 | like | Small steps, forces you to think differently | ||
N**-2 | like | It reduces the risk of bugs. | ||
N**-2 | like | The confidence that the older code is still working as intended | ||
N**-2 | like | Avoid bugs | ||
N**-2 | like | solve one problem at a time | ||
N**-2 | like | Makes it easy to focus on one particular behavior that you're working with. | ||
N***-1 | like | Confidence that my code works | Well tested code. Tests written can be reused for automation testing. Relatively simple at first. | |
N***-1 | like | Confidence that my code works | I like being confident that my code works | |
N***-1 | like | Fast feedback | hey what are you saying | |
N***-1 | like | Fast feedback | I like the building up of the design based on passing small tests for behavior. | |
N***-1 | like | Fast feedback | I like the quick feedback about my code | |
N***-1 | like | Fast feedback | Learning to code in incremental steps which helps in early bug detection | |
N***-1 | like | Find problems quickly | this is a test | |
N***-1 | like | Find problems quickly | Catching errors quickly | |
N***-1 | like | Find problems quickly | Small changes let you find the problems quickly. | |
N***-1 | like | High test coverage | I like being told what parts of my code are not covered by tests | |
N***-1 | like | Other. | Helps to find small bugs like typos right off the bat. | |
N***-1 | like | Other. | A good approach to testing, the instructor is helpful. TDD can help break the problem into smaller chunks may help converge to the solution faster. | |
N***-1 | like | Structured approach | The code came together well at the end and you know it's decent code because it was tested | |
N***-1 | like | Structured approach | Very methodical and thought process is traceable assuming we use version control for intermediate checkins. | |
N***-1 | like | Instant ~gratification~ feedback | ||
N***-1 | like | Knowing when a change broke something that previously worked. | ||
N***-1 | like | It makes writing code kind of like a game | ||
N***-1 | like | Easy to use (once the environment is setup). | ||
N***-1 | like | I like that I can focus on one thing at a time and get instant feedback. | ||
N***-1 | like | I like the fast feedback loop and feeling of continual progress as tests are added, fail, then made to pass. It seems like all this testing may lead to fewer bugs in the code, but I'm not convinced just yet... | ||
N***-1 | like | Tests seem to be easy to setup and run through. | ||
N***-1 | like | I like how it easily put me into a stuctured work flow | ||
N***-1 | like | I like how quick it is to complete small tasks. | ||
N***-1 | like | I like it seems that each test seems to correspond with the creation of a task. | ||
N***-1 | like | Finding issues with code | ||
N***-1 | like | The process is pretty fun and it's satisfying to see all those tests passing | ||
N**-2 | like | All the above. | I liked the immediate feedback and focus on the code as it is being written. | |
N**-2 | like | Confidence that my code works | Interactive and live environment to build as we go... | |
N**-2 | like | Confidence that my code works | Felt safe refactoring when I needed to go back and change something. | |
N**-2 | like | Fast feedback | I like the time between the tests failing and tests passing. | |
N**-2 | like | Fast feedback | makes programming simpler. you know what you have coded so far works. | |
N**-2 | like | Find problems quickly | I like that there is an iteration process of a failed test followed by a pass test and once you are finished you have all of your tests setup. | |
N**-2 | like | Fun | It is almost like learning a new programming language from scratch. So, you start from the basic, and you work your way up. | |
N**-2 | like | High test coverage | Re enforcing don't write code you don't need. I liked how in your instructions you stated 'you do not need dynamic allocation yet' and 'gets were static'. | |
N******-2 | like | Writing test functions first enforces you to think differently on your code behaviour and architecture. | ||
N******-2 | like | Gradually get to reliable implementation | ||
N******-2 | like | interesting way to build up code | ||
N******-2 | like | TTD took me to simple end solution that I didn't imagine at the start of API creation | ||
N******-2 | like | > pushing me to think one step forward in possible failure scenario > making me excited again about programming | ||
N******-2 | like | To test basic functionality of functions. | ||
N******-2 | like | It's a systematic process | ||
N******-2 | like | Forces you to test instead of just assume. | ||
N******-2 | like | Seems to force you to write more modular and independent code as you need to test it down to a unit. Better defines a unit. | ||
O****-1 | like | I like the impression of forcing the code to "behave", no matter what I change later. | ||
O****-1 | like | it helps getting rid of bugs during development. It kept me on track | ||
O****-1 | like | I'm not scared of changing the code. | ||
O****-1 | like | It gives you a predefined and safe way to well implement your code | ||
O****-1 | like | testing functions in small steps | ||
O****-1 | like | The posibility to test small pieces of software | ||
O****-1 | like | It seems easy to do now. | ||
O****-1 | like | Thinking about some months ago: The persistence of the tests. Before I always dropped the tests again. | ||
O****-1 | like | It helps keep thinking in small steps. To not loose the thread. | ||
O****-1 | like | To have the (all) tests running in parallel with development | ||
O****-1 | like | Seems that getting the right tests makes it easy to avoid hidden bugs or code errors | ||
O****-1 | like | I like that if you have finished implementation you also have finished testing! You have to test anyway, so extra time effort my not be so big (if good toolchain) | ||
O****-1 | like | the bug finding is immediately | ||
O****-1 | like | Divide & conquer approach Fast and reliable feedback on changes | ||
P***-1 | like | 1) I love programming & getting the tests done with more programming is an interesting option. 2) TDD encourages you to think more about boundary cases since your doing one step at a time | ||
P***-1 | like | Find test cases and making sure these are taken care of during development. | ||
P***-1 | like | you don't need to wait till the end of coding to verify your code. you can test your code incrementally. | ||
P***-1 | like | TDD helps improving the design | ||
P***-1 | like | Quick feedback about code function | ||
P***-1 | like | Compactness, less chance of overlooked bugs. | ||
P***-1 | like | Testing and Development achieved side by side with ease and bug-free (which of course depends on the test cases coverage). | ||
P***-1 | like | Step wise approach forces solving one problem at a time | ||
P***-1 | like | writing testing code which challenges the basis of writing actual feature code | ||
P***-1 | like | Encourages to take the problem in manageable chunks | ||
P***-1 | like | Knowing about TDD and working on sample program - is good. Concept of development during coding phase using TDD is going to help me definitely. | ||
P***-1 | like | Prevents- implement the whole thing then try it. | ||
P***-1 | like | Helps catching logical checks like true or false, out of boundary conditions BASED on how efficient once can write the test code. If test fails, analyzing seems easy and fixing the code seems easy. | ||
P***-1 | like | - Minimizes integration defects. - Helps to build cleaner interfaces. - Less code changes after development so reduce patches. | ||
P***-1 | like | It was a good exercise as it was giving an insight that what we are actually implementing and what would be my end result to implemented code in different circumstances. | ||
P***-1 | like | Test before coding | ||
P***-1 | like | New perspective about coding the software. | ||
P***-1 | like | 1) Bugs can be prevent at the first time, not later time. 2) Test cases designed in the past can be used to prevent degrades by new changes. | ||
P***-1 | like | Finds bugs, provides a consistent method for teaching other developers, of varying skill level, to create better code. | ||
P***-1 | like | TDD gives you confidence that your code works as intended. | ||
P***-1 | like | The test suite gets built from the beginning of the development. | ||
P***-1 | like | Develop bug free code. | ||
P***-1 | like | how it can make you think the design | ||
P***-1 | like | Find more problems during development. | ||
P***-1 | like | the idea of TDD is very good. Development is focused on passing the current tests, and not breaking current tests when adding a new test | ||
P***-2 | like | structured thinking | ||
P***-2 | like | Test code is already there when I finish product coding. | ||
P***-2 | like | Use case based -Test Cases would be created before hand hence code quality could be better if the test cases are comprehensive | ||
P***-2 | like | Systematic approach to the methodology. | ||
P***-2 | like | test each and every line of code while development test all possible positive and negative paths | ||
P***-2 | like | TDD will reduce the time spent in debugging | ||
P***-2 | like | Orderly Patterned Structured | ||
P***-2 | like | Going back to the Crux of programming to take baby steps to develop code. I think it is quickest way to identify and solve problems that may come back as bugs later. | ||
P***-2 | like | Test code available before development of the code which makes step by step progress which will avoid frustration when trying to do it all together. Will have more confidence on the code as unit testing is complete and you have less things to worry about | ||
P***-2 | like | provides a step by step approach to problem solving | ||
P***-2 | like | Enhance programming efficiency and help keep the code organized | ||
P***-2 | like | 1) Its ability to identify lower granular issues in a code. | ||
P***-2 | like | It keeps programmers write less error-prone code | ||
P***-2 | like | It's easy and fast to detect and fix errors. | ||
P***-2 | like | All the unit test cases are written based on the requirements. What we need to concentrate on is to make sure the test cases are passed and write the code for it. This will make sure requirements are met and unit is robust. I like that it drives to write the correct code. | ||
P***-2 | like | concept is new to me. would be better if I learned this at college | ||
P***-2 | like | |||
P***-2 | like | TDD seems to be good way to step through the development of Coding while preventing bugs. | ||
P***-3 | like | test cases created before/during development. | ||
P***-3 | like | 1. writing Test case is very simple. 2. TDD ensures end to end functional flow. | ||
P***-3 | like | Coding and Testing. | ||
P***-3 | like | TDD's ability to create long-lasting and relatively bug-free code | ||
P***-3 | like | Code was written out naturally by satisfying test cases. | ||
P***-3 | like | Helps in Maintain code quality. Since on adding new code/features if existing test case fails then they can be fixed right away. | ||
P***-3 | like | You are able to ensure each function is working as expected during development. | ||
P***-3 | like | Coding and testing are done at the same time. | ||
P***-3 | like | Testing code immediately after writing | ||
P***-3 | like | Avoiding repeated coding errors and making it a habit | ||
P***-3 | like | I liked being able to see what problems still existed as code was implemented by having previous test cases begin to fail. | ||
P***-3 | like | 1. Methodical one-step-at-a-time file modification discipline. 2. Ability to refactor | ||
P***-3 | like | 1. Writing code in iteration. 2. Writing only that much code which can be tested. | ||
P***-3 | like | Defects can be found during implementation. | ||
P***-3 | like | TDD really helps to Run Regression tests for all the test cases which were earlier passing before making the code changes. | ||
P***-1 | like | It structures the code. | ||
P***-1 | like | I like that you get another view/approach on solving a problem. | ||
P***-1 | like | Reassurance that your code (as it is at this point) works. | ||
P***-1 | like | - Small simple, and easy to understand chunks of code (probably not in a real application though). | ||
P***-1 | like | Makes the code easier to maintain. | ||
P***-1 | like | provides a structured way of thinking | ||
P***-1 | like | - Catching mistakes early. | ||
P***-1 | like | Confident code will work | ||
P***-1 | like | wrapping my brain around trying to do as little as possible to make it pass, i.e. procrastinate | ||
P***-1 | like | Code is regression tested at every step | ||
P***-1 | like | Every new passing test is like some patting you on the back saying "Good work!" :-) | ||
P***-1 | like | Try to find the simplest solution to solve only the problem in front of you | ||
P***-1 | like | It helps me to focus on smaller pieces of the problem. I tend to take in too much complexity at once | ||
P***-1 | like | You always see some progress in the development, inspiring to get tests passing Easy to have confidence that the code is correct after refactoring | ||
P***-1 | like | Creating the API early. Being able to get back exactly where I was when switching contexts. Dividing the task into multiple smaller problems. | ||
P***-1 | like | I like the feeling of progress. It is motivating to not having to take any large steps in the wrong direction. | ||
P***-1 | like | It does make it difficult for you to enter several bugs at a time and help you catch them early. | ||
P***-1 | like | It's addictive :-) | ||
P***-1 | like | It increases the focus on "what" | ||
R*-1 | like | Fun | fun | |
R*-1 | like | Fun | fun | |
R**-1 | like | All the above. | It makes absolutely sure the code I write is testable. It makes absolutely sure I have tests. It makes it easy to add regression tests later. | |
R**-1 | like | All the above. | TDD helps you to avoids errors already during implementation. | |
R**-1 | like | All the above. | I enjoy exercices | |
R**-1 | like | Confidence that my code works | Verifying code on the go made me confident about it. I am pretty sure the code I have made is working | |
R**-1 | like | Confidence that my code works | It is an excellent tool for refactoring. | |
R**-1 | like | Fast feedback | Complete new way of thinking about writing functionality | |
R**-1 | like | Fast feedback | if you invest time writing tests beforehand, it gives fast feedback if methods/code do as intended.. | |
R**-1 | like | Find problems quickly | Easy to track down the issues | |
R**-1 | like | Find problems quickly | Since we work step by step, we find the problem more quickly | |
R**-1 | like | Fun | The exercise environment (cyber dojo) is really cool. | |
R**-1 | like | High test coverage | See the deviance directly | |
R**-1 | like | High test coverage | Someone who wants to modify my code will have to respect all my tests (given he doesn't just strip the tests down, but that's another topic). | |
R**-1 | like | High test coverage | It turns my world upside down. | |
R**-1 | like | Minimal implementation | Dealing with a very focused code, and minimal change | |
R**-1 | like | Other. | I had a feeling that I already knew quite well what TDD was about, but I had a wow effect about points I didn't see before. | |
R**-1 | like | Other. | I like how the incremental approach makes my code change and evolve allowing me to go from stupid to more complex as the test become more demanding. | |
R**-1 | like | Structured approach | I like the structure coding approach TDD forces you to do so | |
R**-1 | like | Structured approach | Do not really know yet... | |
R**-1 | like | Structured approach | The structure makes sure I am less likely to forget steps/things | |
R**-1 | like | Structured approach | It seems to be a good way to cut a problem into "small pieces". | |
R**-1 | like | Structured approach | We have a very structured structure | |
S***-1 | like | All the above. | It makes you focus on one thing at a time. | |
S***-1 | like | Confidence that my code works | Gives more initial confidence of code and tests. I also enjoy breaking the code and tests several times, before moving onto further development. It fulfills my violent urges. | |
S***-1 | like | Fast feedback | I like the instant feedback and I only wrote code I needed. | |
S***-1 | like | Fast feedback | It was methodical and immediately let you know if something broke while adding new features. | |
S***-1 | like | Fast feedback | I like the inherent incremental and iterative development | |
S***-1 | like | Find problems quickly | rapidly detecting errors, mostly the ones i caused. framing tests drives production software, only builds capability needed for test. iterative development | |
S***-1 | like | High test coverage | I like that all the code I write is being tested and that the tests don't need continual manual updates. | |
S***-1 | like | High test coverage | You are building your tests as you develop rather than doing it after the fact. | |
S***-1 | like | Minimal implementation | I liked moving forward in small chunks. Each step was very simple. | |
S***-1 | like | Structured approach | I like out tests build on each other to keep your code honest. | |
S***-1 | like | Structured approach | It's systematic in its approach. | |
S***-1 | like | Structured approach | I liked how you could start with very basic tests and make sure your initial thinking is correct for a structure and functions. | |
S****-1 | like | It makes you think about the correctness of the implementation one step at a time | ||
S****-1 | like | small, short cycles, fast tangible results. creating these tests this way makes me really trust them. | ||
S****-1 | like | The exercise really helped me understand the TDD process: test first, code later. | ||
S****-1 | like | Being able to add functionality without worrying about previous functionality | ||
S****-1 | like | Design first approach | ||
S****-1 | like | Design thinking/considerations during coding | ||
S****-1 | like | Testing your code step by step, while you write it. | ||
S****-1 | like | High testcoverage | ||
S****-1 | like | You get good test coverage more or less automatically through this approach | ||
S****-1 | like | You could see how simple bugs or mistakes can be captured quickly | ||
S****-1 | like | The code grows in small steps, incremental approach | ||
S****-1 | like | Testing considerations during testing, when implementation is finished, (unit) testing is also finished | ||
S****-1 | like | The TDD aproach develops test and implementation simultaneously. | ||
S****-1 | like | The implementation will testable | ||
S****-1 | like | Short feedback-loop | ||
S****-1 | like | - That you're starting with testing immediately - Focus on expected behavior instead of implementation | ||
S****-1 | like | Each test will detect a separate issue (1 failure in production code should result in 1 failed test case) | ||
S****-1 | like | Gives a good foundation of unit tests (lower part of testing pyramid), which results in more effective higher test levels | ||
S****-1 | like | Short cycle times | ||
S****-1 | like | quick verification of the code | ||
S****-1 | like | fast feedback | ||
T***-1 | like | 851 | like 851 -- revised, again, and once more | |
T***-1 | like | everything | what;'s not to like. some other stuff, and even more now. now what. and another line And then some | |
T***-1 | like | this | this and that | |
T**-1 | like | co-development | Encourages thinking about how code should be tested while developing | |
T**-1 | like | feedback | Quick feedback for both my successes and failures. | |
T**-1 | like | flow | Good work flow (write tests first, build on-top of tests). | |
T**-1 | like | forced perspective | I enjoyed the minimal development approach. It forced me to adopt another perspective for debugging | |
T**-1 | like | good | good overview enjoyed the practical so far | |
T**-1 | like | GOOD | It is a good learning experience so far. It gives a good structural/procedural (test) approach to developing code while solving problems. | |
T**-1 | like | language | Not a new language to learn, more or less | |
T**-1 | like | Piecemeal | Forces you to think in little (testable) pieces | |
T**-1 | like | Safety | A different approach to development. Only implement what you need right now without looking into the future, and testing each step makes it very safe for when you need to refactor. | |
T**-1 | like | simple | Can concentrate on very small functionality at a time. | |
T**-1 | like | Unsure | I don't know enough to know what I like about it just yet. | |
T**-1 | like | working | The ability to keep code working. | |
U**-1 | like | All the above. | Easy to use and clear evolution of the testing regime as you progress. Encourages revisiting of previous work to improve test coverage. | |
U**-1 | like | All the above. | The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this | |
U**-1 | like | All the above. | I liked the modularity, the step by step programming. I liked also how easy is to make in code something you have in mind. It like a guided procedure | |
U**-1 | like | All the above. | The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this | |
U**-1 | like | All the above. | The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this | |
U**-1 | like | Confidence that my code works | Didn't need to try and solve the whole problem at once. Incrementally built solution as added tests by refactoring code. | |
U**-1 | like | Confidence that my code works | It designs the tests ahead of the code. | |
U**-1 | like | Confidence that my code works | I can use it to progress in controlled manner so that I'm forced to think about what I'm doing | |
U**-1 | like | Confidence that my code works | Confidence that new code won't break the behaviour already done. | |
U**-1 | like | Confidence that my code works | Being able to focus on one small thing at a time when writing new code. Knowing that the test will catch issues when I make a change later. | |
U**-1 | like | Confidence that my code works | Being able to focus on one small thing at a time when writing new code. Knowing that the test will catch issues when I make a change later. | |
U**-1 | like | Fast feedback | simple approach to breaking down a problem | |
U**-1 | like | Fast feedback | I like how fast is to run the code after writing that. I mean, you don't need to compile all the flash image, flash target and test, the code runs immediately after doing it. | |
U**-1 | like | Find problems quickly | Liked the approach as it allows to start testing at early stage. | |
U**-1 | like | Find problems quickly | I like find bug when I change code | |
U**-1 | like | Find problems quickly | I like find bug when I change code | |
U**-1 | like | Find problems quickly | I like find bug when I change code | |
U**-1 | like | Fun | It is more interactive. | |
U**-1 | like | High test coverage | It forces you to test every line of code. | |
U**-1 | like | High test coverage | It is some fun. It gives the impression that you have full control over the code you are writing. Separation between tests and production code is natural | |
U**-1 | like | Minimal implementation | Not need to focus on the entire problem at once. | |
V****-1 | like | Fast cycle time | ||
V****-1 | like | Incremental approach to implementation | ||
V****-1 | like | Solving the simplest problem at a time makes it a lot easier. | ||
V****-1 | like | It's very organized and meticulous. In the end, what you have is working. | ||
V****-1 | like | I liked that the code was written as the tests were developed. | ||
V****-1 | like | It helps focus on one element of the design at a time | ||
V****-1 | like | when development is done, test is in place reinforce the coding discipline | ||
V****-1 | like | instant feedback | ||
V****-1 | like | I like that we tackle one facet of the problem at a time. | ||
V****-1 | like | Like the workflow and it helps to add structure and steps to what now takes place between my ears when coding. | ||
V****-1 | like | quick feedback loop | ||
V****-1 | like | lock down behavior, so that when the code has to change, you know that previous behaviors are still preserved. | ||
V****-1 | like | Freedom to experiment with implementation and know quickly when I inevitably broke something | ||
V****-1 | like | Makes you think about the boundary conditions Helps you answer requirement questions | ||
V****-1 | like | able to refactor confidently | ||
V****-1 | like | automated testing | ||
V****-1 | like | Different way to approach a problem. Was reassured my code worked after changes. | ||
V****-1 | like | Having the test bed makes it easier | ||
V****-1 | like | Previous tests breaking helps to quickly point out problems with recent changes | ||
V****-2 | like | easier testing | Made testing code easier. | |
V****-2 | like | Helps | Helps you catch bugs early on | |
V****-2 | like | incremental | Made inclemently implementing features easier. | |
V****-2 | like | Interesting | TDD is a good a approach to systematically solve a programming problem, as the bugs can be fixed on the go. | |
V****-2 | like | interesting | It gave me an idea of how to write fewer bugs in my code. | |
V****-2 | like | like | incremental development. validate, test, necessity of a , need for variables in microscopic details. emphasis on code coverage | |
V****-2 | like | Promotes safe coding | It's more fun to program, knowing you will have better code coverage. With the test in place, it provides other team members the ability to step through existing code | |
V****-2 | like | Test while develop | I liked the idea as it allows you to test while you are developing your module. | |
V****-2 | like | Useful-test-platform | Reduces future debugging efforts, able to catch the bugs early. | |
V**-1 | like | Amazing | The training is amazing! I like the learning method (nice presentation + practical excercies) to understand TDD better | |
V**-1 | like | Confidence | TDD helps when writing the code and I feel more confident when I deliver the code. The real benefit I think is later - the code stays tested over time. | |
V**-1 | like | Confidence | Creates confidence about the code being developed. | |
V**-1 | like | consistent behavior | It helps to secure that existing code works when making changes or refactoring. | |
V**-1 | like | control | More control on production code | |
V**-1 | like | Coverage | I liked the fact that when you are done "TDD-ing", you are actually finished with your work and have good test coverage without having to go back and add tests afterwards | |
V**-1 | like | Design help | TDD helps to chisel out the interfaces to functions/methods. If I have a hard time testing the function there might be a wrong abstraction level. | |
V**-1 | like | done | Tests are done when you are. | |
V**-1 | like | Easy | TDD is much easier than I tought. | |
V**-1 | like | efficient | The quick feedback about our code. | |
V**-1 | like | Expectation | You tend to think more about the expected outcome before make changes. | |
V**-1 | like | Feedback | Fast feedback. It's rewarding to get lots of successes | |
V**-1 | like | Feels confident | Gives enough satisfaction about the code written. | |
V**-1 | like | FewerBugs | It is easy to trace | |
V**-1 | like | iterativ | fast feedback with small changes | |
V**-1 | like | iterative | The iterative approach to tested when done | |
V**-1 | like | K.I.S.S | I liked the fact that you "eliminate" adding code that is not necessary and thus keep complexity to a minimum | |
V**-1 | like | More practice | I get to write a lot of code. Since I have to write test code, I get more practice on the actual code creation. | |
V**-1 | like | New | Learning a new development approah, writing a test before writing the implementation. | |
V**-1 | like | Progress | The instant feedback of progress. | |
V**-1 | like | Quality | Quick feedback loop when implementing -> continuous improvement. | |
V**-1 | like | Rewarding | It is rewarding to see the result immediately (not so rewarding when breaking a test ;-) ) | |
V**-1 | like | safety net | easy to change without risk of breaking something | |
V**-1 | like | Structure | Enforces you to not add unnecessary code -> adds structure to the process of implementation. | |
V**-1 | like | time saving | saves time otherwise spent debugging | |
V**-1 | like | Traceable | it is easier to trace where we went wrong in the code. and took less time to fix it. | |
W****-1 | like | I enjoy refactoring with fewer concerns that things are breaking | ||
W****-1 | like | Regressions are caught sooner and silent errors are being caught. | ||
W****-1 | like | Getting instant feedback on whether the code works. | ||
W****-1 | like | Thinking about how to test whatever you come up with, before you start. The accumulation of a comprehensive test suite. | ||
W****-1 | like | Can lead to solid principles and practices. | ||
W****-1 | like | TDD drives the design. | ||
W****-1 | like | Keeps the scope of the bugs small, mostly singular. | ||
W****-1 | like | Step by step progression through the development that detected errors quickly that were easy to fix because they just happened. | ||
W****-1 | like | Provides instant, focused, feedback when mistakes (typos or design errors) are made. | ||
W****-1 | like | I liked how when all of the tests are running together it gives you a real understanding if your system is bug free or not. It shows if the tests written earlier are still valid. | ||
W****-1 | like | Releases one from the concerns regarding refactoring because you have tests to prove the behavior has not changed (unless desired). | ||
W****-1 | like | Seeing multiple tests fail lets you more quickly identify the problem when a method has changed | ||
W****-1 | like | I like the approach of defining the tests that the code must pass and then writing the code to satisfy those tests. | ||
W****-1 | like | Enforces good methodology. | ||
W****-1 | like | I liked how early bugs are recognized. | ||
W****-1 | like | always working on small an d specific amount of code | ||
W****-1 | like | Writing the tests first ensures that they get written. | ||
W****-1 | like | It seemed to be a process and we need more processes here. | ||
W****-1 | like | it keeps you from thinking too much and just gets down to writing code. | ||
W**-10 | like | I wrote a circular buffer and never had to debug anything. | ||
W**-10 | like | I like that these tests will constantly run during development. If anything breaks, we'll know it quickly. | ||
W**-10 | like | I liked the ability to keep the work as simple as possible | ||
W**-10 | like | Makes you think about the API of your code. | ||
W**-10 | like | good for the low-level 'code/test repeat' cycles | ||
W**-10 | like | I liked having tests that would work as a safety net | ||
W**-10 | like | I liked how it organized your thoughts on how to build the code. | ||
W**-10 | like | Ongoing quick feedback of regression. | ||
W**-10 | like | The simplicity, only deal with one thing at a time. | ||
W**-10 | like | Focuses on the minimal solution -- helps keep people from going too deep. | ||
W**-10 | like | Clear 'focus' -- you don't need to have 'everything' in your head at once, instead just focus on doing something well. | ||
W**-10 | like | It was fun. About what I expected from reading your book. | ||
W**-10 | like | Makes you think about what you are doing. | ||
W**-10 | like | love getting re-usable regression tests (almost) for free. | ||
W**-11 | like | It gives me a nice flow to the code creation. Helps me organize my steps. | ||
W**-11 | like | the confidence that comes from small steps | ||
W**-11 | like | Very small steps and thus a lot of small "success stories" | ||
W**-11 | like | Continually building known good code. I know as soon as a I break an earlier test, and can fix immediatly. | ||
W**-11 | like | hard to get into too much trouble | ||
W**-11 | like | Concept of development with testing. | ||
W**-11 | like | You get a complete test coverage from the start. | ||
W**-11 | like | Immediate feedback. | ||
W**-11 | like | The fact that the test is written against the requirement, not against the code | ||
W**-11 | like | Safety net for refactoring is nice. Focus on a single small problem in each test. | ||
W**-11 | like | Test before requirement. Rapid turnround on a compile or test run | ||
W**-11 | like | You know where in the code to look if something fails since you write so little between each test | ||
W**-11 | like | Felt like a structured way to work. | ||
W**-11 | like | That I feel secure with my changes. If I make an error, it will show immediately. The functionality grows in its own "silo". The tests that we write is relevant. | ||
W**-11 | like | Working the baby steps of TDD (had to mentally stop myself from running ahead). | ||
W**-11 | like | It makes you write tests that probably wouldn't have been written otherwise. | ||
W**-11 | like | Driving code by test will make sure that tests are written and that these are releveant | ||
W**-11 | like | Small steps programming. | ||
W**-11 | like | Helpful to be pushed to do only 1 thing at a time. Hard, but helpful to do the simplest thing that passes the test. No extra code. | ||
W**-11 | like | Don't need target HW to run tests during early phases of development | ||
W**-12 | like | From what I have read so far, it is nice to instantly get feedback over what my code is doing. I have had some very very difficult bugs to find in the past (e.g. overflow on a U16 in a control loop) that would cause intermittent failures. If I had TDD on that code, we would have fixed it, and moved on with our lives. Instead, that bug persisted for 1 month :( | ||
W**-12 | like | TDD gives you quick feedback so you only dig a small hole you can fix now, not a giant one that will need to be fixed later. | ||
W**-12 | like | It flagged up errors as soon as they were created. | ||
W**-12 | like | It forces you to think about the working of the code. | ||
W**-12 | like | Showed up stupid errors quickly | ||
W**-12 | like | It helps to test earlier in development. | ||
W**-12 | like | - It forces you to think about functionality - It makes you try to write as simple code as possible | ||
W**-12 | like | Structured and sequential, seems like it is easy to build step by step | ||
W**-12 | like | I've liked building the code by looking at the test requirements first | ||
W**-13 | like | How hard it will be for forget stupid(simple) tests. | ||
W**-13 | like | Get the test skeleton right before full blown code design | ||
W**-13 | like | It forces you to write small verified code. Written tests ensures code continues to function correctly and detect any bug immediately. | ||
W**-13 | like | I like that you get to try out the interfaces you defined immediately. | ||
W**-14 | like | Testing framework is pretty clean. The macros and reusable functions, as well as the built in setup and teardown functions are handy. | ||
W**-14 | like | The safety net that gets built as we progress | ||
W**-14 | like | Very nice example when changing from array to pointer. Very good to see the old tests running. | ||
W**-14 | like | Catching errors early. | ||
W**-14 | like | I like the iterative approach which makes you think how you are going to develop the feature | ||
W**-14 | like | gives a good principle how to write code that is tested at the same time | ||
W**-14 | like | It was new thing for me but i got the idea pretty quickly. Everything was explained step-by-step. | ||
W**-14 | like | instant feedback if something is wrong. Bugs should be caught faster | ||
W**-15 | like | Test planning and determining desired program behavior prior to implementation. | ||
W**-15 | like | Helps with Design. | ||
W**-15 | like | forces stepwise refinement of the code | ||
W**-15 | like | Removes the "It's so boring to write test cases" by integrating them with the design. | ||
W**-15 | like | Great for writing provable (to a point) reliable code. | ||
W**-15 | like | I like how it makes you think about problem in a testable way. I like how unit tests provide me quick feedback about unexpected features. | ||
W**-15 | like | How it forces the break down of work to very small pieces. | ||
W**-15 | like | It's good at catching bugs and when done right seems to help guide you towards an interactively better solution to a problem that is highly likely to bug free. | ||
W**-15 | like | continuous validation | ||
W**-15 | like | Seems to be a lot more efficient than my usual workflow of "write a bunch of stuff-> hope it works -> spend a bunch of time fixing what doesn't" | ||
W**-15 | like | Potentially thorough code coverage at the beginning of the software lifecycle. | ||
W**-16 | like | Fast rewards | ||
W**-16 | like | It seemed to work | ||
W**-16 | like | I like that we now have tests that can be run 6 months down the road when someone else changes the code and be able to verify everything still works. | ||
W**-16 | like | I like the small step approach. | ||
W**-16 | like | +Your test go with the development hand in hand. | ||
W**-16 | like | Seeing the added functionality and what happened in older tests. | ||
W**-16 | like | I have never tried CppUTest so that was good experience. | ||
W**-16 | like | It kept things somewhat simple, from a code perspective | ||
W**-16 | like | +The test will remain written (contrary to my old system of playing with the debugger), so that regression tests can be done in the future. | ||
W**-16 | like | It keeps the code base tested as it grows. | ||
W**-16 | like | always knowing that the previous stuff I'd written worked for those specific cases. Giving me a better view of the limitations of the code | ||
W**-16 | like | Having a real reason to add code. Not just guessing this feature could be useful in the future. | ||
W**-16 | like | A systematic away to implement code testing. | ||
W**-17 | like | Small steps in the exercise made sense. Editor recognizes some emacs keystrokes. | ||
W**-17 | like | fast feedback, little steps to do, revert the changes. Its hard at first, but only implement what is actually needed. This could be hardcoded. | ||
W**-17 | like | - Adding new features step by step makes me feel more confident - New code can break older tests. I wouldn't have realizes without them. | ||
W**-17 | like | The rigorous, stepwise process. Even on failure, feels like forward motion. Gives you a safe checkpoint to fallback to if things aren't working out. Also gives you a safe point to sit back for a bit and evaluate the successful stuff and see if it can be improved. Motivates you to keep going, keep producing something. | ||
W**-17 | like | Simply applying TDD drives better architectures. | ||
W**-17 | like | cool | ||
W**-17 | like | beyond cool | ||
W**-17 | like | 1105 | ||
W**-17 | like | like 1116 | ||
W**-17 | like | 99999 | ||
W**-17 | like | like 1128 | ||
W**-17 | like | like 1133 | ||
W**-17 | like | like friday | ||
W**-17 | like | 931 | ||
W**-17 | like | 1014, that is it | ||
W**-17 | like | I was kept from being overwhelmed - continual small progress kept me flowing continually. I didn't need to think about all of the implementation details up front. Refactoring was painless and straightforward. | ||
W**-17 | like | I like the quick iteration/feedback cycle. It is very useful knowing that a bug was written in the last few minutes, for example. | ||
W**-17 | like | It reduces the amount of information that I have to store in my head at any given time. | ||
W**-18 | like | confidence | I liked the confidence of knowing that the code worked and that I didn't break things that used to work. | |
W**-18 | like | feedback | It gives rapid feedback, allowing you to see what mistakes you've made almost as soon as you've made them. | |
W**-18 | like | incremental | Incremental progress. | |
W**-18 | like | interesting | Its an interesting way to test software. Which is a new experience for me. | |
W**-18 | like | intriguing | Gave me a new perspective on Software development. | |
W**-18 | like | Learning | Learning about CPPU Test and a different development methodology and how I can apply it to my development style. | |
W**-18 | like | quality | confidence in quality of code. If you write good tests, after you're done, you're more confident that it works, and you can be more confident in refactoring it later. | |
W**-18 | like | tooling | The online coding environment prevents configuration management issues which might otherwise hold us up. The test set itself provides an efficient way to communicate a design path for attendees | |
W**-18 | like | Understandable | The environment was easy to use and the exercise is good. The circular buffer seems to be a fitting example to write tests for. | |
W**-18 | like | web UI | I liked the little web app UI, except I found myself hitting ctrl-S a lot, maybe bind that to "Run Tests"? | |
W**-19 | like | Automation | Testing is done for you. | |
W**-19 | like | confidence | You can add new features with more confidence that prior functionality will not get broken, since your old tests continue to pass | |
W**-19 | like | Confidence | TDD gives you confidence about your code. | |
W**-19 | like | different | Provides a different way to view development. | |
W**-19 | like | Instant Feedback | Instant feedback if code is broken. | |
W**-19 | like | Memory | Reminds you where you are on a task if you get distracted | |
W**-19 | like | methodical | Very methodical. I liked slowly working through all the implementation details through specific tests. | |
W**-19 | like | Task Creation | Breaking down a large task into multiple smaller tasks | |
W**-19 | like | Test Coverage | The test coverage you're left with once complete. | |
W**-20 | like | bite-sized | Small steps: I like that each step is small, minimizing cognitive load | |
W**-20 | like | lego | Short iteration with short implementation. You get more understanding of the code that you write. | |
W**-20 | like | methodical | The ability to test along the way ... takes care of the unit testing | |
W**-20 | like | regularity | I like the regularity of the steps: do the same process, one bit at a time | |
W**-20 | like | reliable | I like that you test as you go and so your code is more reliable. | |
W**-20 | like | safety-net | I like how the tests seem to "lock in" the behavior as you go along | |
W**-21 | like | Clean Code | I like about incremental approach of development of the TDD. It keeps the code clean and beautiful. It's fun to write tests, fail it and then pass it. | |
W**-21 | like | Easy & Useful | I like the way TDD approach enforces developer to consider what you want from the code.It also controls design of your program. Code implementation is totally driven by unit test cases written. | |
W**-21 | like | exceute | I like the way of writing our own test cases to check the code | |
W**-21 | like | feedback | I like building up quick wins. I know I'm making progress. | |
W**-21 | like | Good Approach | I like the approach of the TDD training session | |
W**-21 | like | Great, confidence, | I feel its great way to developing code, one can be confident it will work. Small pieces to perfection like production. Build/running code always present even it may not fully functional. | |
W**-21 | like | guidance | TDD guides you to a clean interface and minimal implementation. | |
W**-21 | like | mindset change | Fail early, fix quickly | |
W**-21 | like | presence | TDD saves you from thinking about future problems too early. | |
W**-21 | like | Process | It's a process | |
W**-21 | like | regression | Like that it creates way to check other changes that shouldn't change functionality and provides regression | |
W**-21 | like | short and simple | It make us to think about only for current unit test at a time It force us to change mindset not to write all code in one shot | |
W**-21 | like | Small Changes | It forces me to break down the problem into a series of small changes. Most of the time the changes required are simple as well. | |
W**-21 | like | small steps | Like that it forces small steps | |
W**-21 | like | thorough | We are coding while testing. Since we are coding only as much as we are able to test, test coverage is excellent. | |
W**-21 | like | Understanding | It brought attention to logic errors early on, and provides a better understanding of how/why sections of code work. | |
W**-22 | like | Confidence that my code works | I enjoy taking the small steps to make sure the code is correct, both test code and run code | |
W**-22 | like | Confidence that my code works | I like the exercise. I like the process of making the test fail first then pass. I also like the fact that back tests protect future code development. | |
W**-22 | like | Fast feedback | I like that I can get immediate feedback on the performance and behavior of the code that I'm developing | |
W**-22 | like | Fast feedback | Creating code that progresses in complexity across multiple functions as oppose to fully building out one function at a time | |
W**-22 | like | Fast feedback | It shows you something went wrong immediately | |
W**-22 | like | Fast feedback | old mac | |
W**-22 | like | Fast feedback | new mac | |
W**-22 | like | Fast feedback | old 1 | |
W**-22 | like | Fast feedback | new 1 | |
W**-22 | like | Fast feedback | old 2 | |
W**-22 | like | Fun | after updating email | |
W**-22 | like | High test coverage | Completion and actuation of high level features before low level realization. Usable regression record that builds during development | |
W**-22 | like | High test coverage | I like the idea of consistently testing code during development. | |
W**-22 | like | High test coverage | I like the idea of consistently testing code during development. | |
W**-22 | like | High test coverage | I like the idea of consistently testing code during development. | |
W**-22 | like | High test coverage | I like the idea of consistently testing code during development. | |
W**-22 | like | High test coverage | It's organized and thorough | |
W**-22 | like | Minimal implementation | Is this unit test macros available to use. easy to modify for our output needs? | |
W**-22 | like | Minimal implementation | making small changes at a time | |
W**-22 | like | Structured approach | It forces me to think about other use case than only the use case I have at the time of writing a class. | |
W**-22 | like | Structured approach | With incremental coding comes very many successes! :) | |
W**-23 | like | Confidence that my code works | Never being very far from code that works. | |
W**-23 | like | Confidence that my code works | It gets a designer to think a little harder about implications of a line of code | |
W**-23 | like | Confidence that my code works | I like the feedback the tests provides when refactoring the code | |
W**-23 | like | Confidence that my code works | It's easy to play around with alternative implementations without starting from scratch. | |
W**-23 | like | Fast feedback | hey 1 | |
W**-23 | like | Fast feedback | hey 2 | |
W**-23 | like | Fast feedback | hey 3 | |
W**-23 | like | Fast feedback | like 1024 | |
W**-23 | like | Fast feedback | I don't have to worry about if I break something. This makes me able to focus better at getting things done. | |
W**-23 | like | Fast feedback | test 1 | |
W**-23 | like | Fast feedback | test 3 | |
W**-23 | like | Fast feedback | test 4 | |
W**-23 | like | Fast feedback | test 5 | |
W**-23 | like | Fast feedback | fun | |
W**-23 | like | Find problems quickly | Small changes results in less time in the debugger - I can easily deduct what the problem is. | |
W**-23 | like | Find problems quickly | TDD is good at catching errors very early. | |
W**-23 | like | Find problems quickly | nice to work against something very specific, where the requierements are very clear. no guessing | |
W**-23 | like | Find problems quickly | test 2 | |
W**-23 | like | Minimal implementation | It keeps the focus on exactly the feature that's being implemented | |
W**-23 | like | Structured approach | I like the structure, such that progress is concrete. | |
W**-23 | like | Structured approach | If done in concert with a separate but conjoined design activity, TDD ensures that design intent is met | |
W**-24 | like | All the above. | Being in the flow, quick feedback, reduced cognitive load. | |
W**-24 | like | Confidence that my code works | Building on past success | |
W**-24 | like | Confidence that my code works | Able to validate code as it is written. | |
W**-24 | like | Confidence that my code works | The guarantee that the behavior of previous tests is still in the code | |
W**-24 | like | Confidence that my code works | I like being able to make change without being afraid about breaking something in the process. (Like when we change the buffer from static to dynamic allocation.) | |
W**-24 | like | Fast feedback | I like having the automated tests to catch when I make a coding mistake. | |
W**-24 | like | Fast feedback | There is fast feedback when things are broken. | |
W**-24 | like | Fast feedback | New ways to think on coding with test in minde | |
W**-24 | like | Fast feedback | I don't deep into the problem before I can find it. | |
W**-24 | like | Fast feedback | I like having feedback on just what I wrote instead of waiting to have wrote my whole module and then test it and start debugging the whole module at once because certainly there are errors inside. | |
W**-24 | like | Find problems quickly | verifiable progress | |
W**-24 | like | Find problems quickly | Refactoring was easier to debug because of the previously built up tests. | |
W**-24 | like | Find problems quickly | It forced me to think about the problems at hand before I start coding thinking I know know the problem's soluion. | |
W**-24 | like | Minimal implementation | Taking small steps | |
W**-24 | like | Minimal implementation | TDD forces you to only implement what's required. Also what's implemented has tests. | |
W**-24 | like | Structured approach | I liked that TDD forces you to examine the behavior before starting. | |
W**-24 | like | Structured approach | TDD is something that my group has been doing with a great amount of inconsistency, finding a method and sticking to it will be beneficial. | |
W**-24 | like | Structured approach | I liked that you incrementally build the functionality and are confident that your code works as you go along. You also have tests now that verify that you don't break things as you develop further. | |
W**-25 | like | All the above. | starting with test cases before designing and implementing is interesting and the experience is new to me | |
W**-25 | like | Confidence that my code works | I liked that my code told me when I broke it | |
W**-25 | like | Confidence that my code works | Mandates me to write unit test if I use TDD approach | |
W**-25 | like | Confidence that my code works | When modifying previous code, less fear of breaking already testable behavior. | |
W**-25 | like | Confidence that my code works | We write expected behavior (test) along with our code and verify that expectation is met as we write code. | |
W**-25 | like | Fast feedback | Testing interleaved with development. Instant feedback. | |
W**-25 | like | Fast feedback | When I do break testable behavior, I find out immediately, when I still remember the changes I was making. | |
W**-25 | like | Fast feedback | I said this already, but the framework is pretty easy to work with. | |
W**-25 | like | Find problems quickly | It's nice to have some confidence in code correctness as it's written. The framework seems easy enough to work with. | |
W**-25 | like | Find problems quickly | Mandates writing cleaner code in small units, with lesser chances of breaking something with new code. | |
W**-25 | like | None | not sure if I like it. | |
W**-26 | like | All the above. | easy to focus one thing | |
W**-26 | like | Confidence that my code works | I like that after making changes to the heart of the code, the old tests provide me confidence I didn't break anything. | |
W**-26 | like | Fast feedback | I liked that I was forced to test one thing at a time | |
W**-26 | like | Find problems quickly | If you change something and it breaks a previous test, you know immediately. | |
W**-26 | like | Find problems quickly | Made me slow down and think about the test and ways the code could fail before writing code. | |
W**-26 | like | Structured approach | It helps break the problem up into small steps and forces me to logically think through the code development. | |
W**-27 | like | All the above. | Its very simple yet can help spot nasty bugs early. Its quick. | |
W**-27 | like | All the above. | I selected all the above. However this is great for a code written from scratch. Wondering how can we use it when we add few lines on a pile of code that function doesn't have an unit test. | |
W**-27 | like | Fast feedback | Find errors with the code almost instantly. | |
W**-27 | like | Find problems quickly | The feeling that you are always progressing | |
W**-27 | like | Find problems quickly | Code design along with the test cases to find potential errors at the beginning | |
W**-27 | like | Fun | When using TTD it gives you natural progression and structure in solving the problem. | |
W**-27 | like | Structured approach | TDD makes you think about HOW the design works and how it can fail | |
W**-27 | like | Structured approach | Very interessting, I definitely liked that the "API" is written before any code changes. | |
W**-27 | like | Structured approach | TDD makes you think about the code incrementally, making it easier to design correctly. | |
W**-27 | like | Structured approach | The way you think: making little increments from the simplest thing | |
W**-28 | like | Confidence that my code works | TDD emphasizes the importance of tests as much as the importance of code. | |
W**-28 | like | Confidence that my code works | I liked that tests were built along with the code. There was less worry about refactoring or adding something would break existing code. | |
W**-28 | like | Confidence that my code works | Refactoring an implementation detail and knowing that nothing existing broke is great | |
W**-28 | like | Confidence that my code works | I like that in then end there will be a fully functional test to go along with code | |
W**-28 | like | Fast feedback | I liked seeing instant results to my failing tests after making them pass. | |
W**-28 | like | Fast feedback | The confidence that when something is done it is truly DONE. | |
W**-28 | like | Fast feedback | Start making progress right away - no analysis paralysis. | |
W**-28 | like | Fast feedback | Short, fast iterations. | |
W**-28 | like | Find problems quickly | I do like that it encourages the breaking down of complex problems into simpler steps. I can defiantly see how this extra time up front could help in the long run. | |
W**-28 | like | High test coverage | I always liked it because it helped me break down problems and force myself to make unit tests up front when I might not go back and do later if not. | |
W**-28 | like | Structured approach | I like how the code is being developed incrementally instead of all at once. It gives you time to be more thoughtful about the code at each step. | |
W**-28 | like | Structured approach | there is a certain structure of doing TDD that helps coding faster/easier to do and manage. | |
W**-28 | like | Structured approach | it's a nice methodical approach and ensures test development as part of the development; there is always something that can run | |
W**-29 | like | Confidence that my code works | I had a safety net when refactoring | |
W**-29 | like | Fast feedback | Fast feedback | |
W**-29 | like | Fast feedback | Getting a pass/fail straightaway is refreshing. | |
W**-29 | like | Fast feedback | I liked getting instant feedback about small changes | |
W**-29 | like | Find problems quickly | It's clear where the error was | |
W**-29 | like | Find problems quickly | I don't have any C++ experience, but I liked that similarly to C#, compiler languages force you to deal with bugs immediately instead of saving surprises for you later. | |
W**-29 | like | Fun | It slows down the process and makes you think about all the edge cases that might occur. Helps break down the process into smaller steps. | |
W**-29 | like | Minimal implementation | I like the approach of incremental development, bakes it easy to break up large tasks into simple problems. | |
W**-29 | like | Other. | Seems to force breaking the task into bite-sized pieces. | |
W**-29 | like | Structured approach | It's thorough. | |
W**-29 | like | Structured approach | Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough. | |
W**-29 | like | Structured approach | Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough. | |
W**-29 | like | Structured approach | Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough. | |
W**-29 | like | Structured approach | Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough. | |
W**-30 | like | All the above. | That the previous tests where able to find bugs in the code. That I feel more sure that bugs due to my big changes will be find by my tests. | |
W**-30 | like | Confidence that my code works | The safety net | |
W**-30 | like | Confidence that my code works | That the code is fully tested when you go to release it. | |
W**-30 | like | Fast feedback | web-30 | |
W**-30 | like | Find problems quickly | I like that it increases my ability to Focus on one thing. | |
W**-30 | like | Find problems quickly | I liked that I got immediate feedback for what was going on with each test. If a test failed, I know exactly what the test is testing and can trace what went wrong. | |
W**-30 | like | Find problems quickly | I appreciate the fact that I'm forced to evaluate not just what a function should do, but also what it shouldn't. | |
W**-30 | like | Fun | Time is flying | |
W**-30 | like | Fun | it is a very unique way of coding and thinking and i like it but it is a bit challenging one too | |
W**-30 | like | Fun | I liked the Code Dojo concept - that made the setup and course stress FREE. | |
W**-30 | like | High test coverage | First thing this is completely new to me. So I liked the thing that I am learning something new. Secondly for each line of code we can write a test case and test it. | |
W**-30 | like | High test coverage | Thoroughly testing individual functionality. | |
W**-30 | like | Minimal implementation | I like the process of TDD. It's like Scrum - when you do it properly it works. First of all see that failing test. | |
W**-30 | like | Minimal implementation | Keeping it simple. | |
W**-30 | like | Structured approach | I could TRY to ignore the future problems bouncing around in my head. | |
W**-30 | like | Structured approach | Test when passed, felt good. Liked how the small each of the steps were - seemed to break down the problem well. | |
W**-30 | like | Structured approach | I liked the idea of writing tests to.. well test all possible outcomes. I have realized that it's not only two outcomes. it was a great experience | |
W**-30 | like | Structured approach | Testing guides your code development. | |
W**-30 | like | Structured approach | Test code is clean. | |
W**-31 | like | Confidence that my code works | it is helpful to know that as I make changes to my code, all the previous code is still being tested. | |
W**-31 | like | Confidence that my code works | The tests verify that the code works. | |
W**-31 | like | Fast feedback | Fast feedback | |
W**-31 | like | Fast feedback | Getting immediate feedback when I make an error | |
W**-31 | like | Fast feedback | Like the small steps. | |
W**-31 | like | Find problems quickly | When I broke the implementation, whilst adding a feature, the failing tests were really useful | |
W**-31 | like | Find problems quickly | Small steps gives you constant feedback. It is easier to see where the problem is introduced. | |
W**-31 | like | Minimal implementation | No need to lose your thoughts in complex functions. | |
W**-31 | like | Minimal implementation | No need to lose your thoughts in complex functions. | |
W**-31 | like | Minimal implementation | No need to lose your thoughts in complex functions. | |
W**-31 | like | Structured approach | This is straightforward method | |
W**-31 | like | Structured approach | Being able to build the interface in a very deliberate way, not getting caught up in implementation without knowing whether it works. | |
W**-31 | like | Structured approach | Makes you really stop to think about the requirements | |
W**-32 | like | All the above. | Very efficient use of time. Nice quick way to start implementing a design without overthinking it. | |
W**-32 | like | All the above. | Developing in short cycles to add one small capability at a time. Having tests for all previously introduced capability gave me confidence that regressions would be quickly discovered. | |
W**-32 | like | All the above. | I like the focus on a smaller problem first. Kinda like putting a puzzle together | |
W**-32 | like | Confidence that my code works | The safety net. It's like a latching system where every time I make progress, it's locked in by the tests... If it breaks I can just undo. | |
W**-32 | like | Confidence that my code works | Nice to see the details. | |
W**-32 | like | Fast feedback | There was instant feedback on how my code was working | |
W**-32 | like | Fast feedback | Error analysis and possible maintenance work are easier and faster | |
W**-32 | like | Fast feedback | I can start writing code and get feedback right away. Sometimes the hardest part of any project is getting started or restarting once you've stopped. | |
W**-32 | like | Fun | It's more fun and less stressful. | |
W**-32 | like | Minimal implementation | Unnecessary code in production code is avoided | |
W**-32 | like | Structured approach | I like that it forces you to focus on getting the results needed in a targeted fashion. I like that the work is done in small chunks. | |
W**-7 | like | Saves me a tremendous amount of tedium. Fun. | ||
W**-7 | like | what I like is how the code starts to grow at the same as we add more tests | ||
W**-7 | like | I'm still understanding, so I'm not sure if like or dislike | ||
W**-7 | like | To know that the testcases I created will test what i'm expecting to test | ||
W**-7 | like | It's just a different paradigm in the way as we are used to program / develop software. I liked the example it was so illustrative. | ||
W**-7 | like | - You can test faster each implementation that you are adding to your code. - You can know that any new implementation is not affecting any other code that you already tested. | ||
W**-7 | like | - I like the approach for bottom up approach of TDD, in the way that you develop only what the tests can probe. But this can also be lead by unsatisfying test, so it is one against other. | ||
W**-8 | like | A lot of time "in the code"; relatively high confidence level after re-factoring that code is still working | ||
W**-8 | like | It gives you immediate feedback for mistakes or successes. | ||
W**-8 | like | It allows complete confidence when refactoring code. | ||
W**-8 | like | After doing 100s of Ring Buffers, this was an interesting experience to build it in a TDD fashion, and I was able to compare it to my previous experiences. | ||
W**-8 | like | It gives me much greater confidence that my code works while I'm designing it. | ||
W**-8 | like | The flow of coding is quite simplistic when running step by step. Typically one write a larger chunk of code. The exact meaning of every API is investigated / discovered. | ||
W**-8 | like | Natural logical progression of test to code growth as you think though the various routes the code could potentially go through. No way to put the cart before the horse. | ||
W**-8 | like | It forces me to think clearly about how to design a module's API. | ||
W**-8 | like | TDD forces logical separation of concerns. Should create higher quality code. | ||
W**-8 | like | I liked getting all test-cases in place first I liked the fail-test way of working | ||
W**-8 | like | An eye-opener. I can see how making this way of working can save time and produce good code. | ||
W**-8 | like | I like that we're building up a regression suite rapidly, piece-by-piece, for our software object. You feel very confident to change code to add new features and refactor because you have that regression suite. | ||
W**-8 | like | I like the iterative approach that quickly gets you to "good" code, assuming your tests have been properly written. You can spend hours testing a system to catch one case, or minutes writing a unit test case. | ||
W**-8 | like | always confident in the state of code. | ||
W**-8 | like | I like the framework but I don't know that the framework for testing is the same as the concept of TDD. I think you use one to do the other. | ||
W**-8 | like | as someone rusty in the language, it gave focus to where i needed a refresh | ||
W**-9 | like | Fast feedback loops | ||
W**-9 | like | Passing tests verify the expectation of how you thing the design should work | ||
W**-9 | like | Great way to catch errors right away. | ||
W**-9 | like | It is satisfying to see the tests go green. | ||
W**-9 | like | TDD makes my life as a developer easier and more sane. I spend less time wondering how on earth my program got into such an unusual state. I am also much more likely to be the first one to find my errors. | ||
W**-9 | like | Makes refactoring code easy and risk free. | ||
W**-9 | like | I like to always have code that runs. Or most of the time at least. Not working for a long time with "broken" code. To be able to focus at one small thing at a time. | ||
W**-9 | like | Be wrong faster, spend less time binary-searching for my mistake. | ||
W**-9 | like | Minimal implementation to fulfill specification | ||
W**-9 | like | TDD allows me to focus on one thing at a time. | ||
W**-9 | like | It was easy to refactor. It was easy to try new ideas and our old tests made sure we did not hit any corner case we had previously solved. | ||
W**-9 | like | clean and effective code | ||
W**-9 | like | Easy to spot errors. | ||
W**-9 | like | I could see errors straight away and it forced me to think about the testing and coding in a new way | ||
W**-9 | like | unit tests provide living documentation and remove the need for (most) comments in code | ||
W**-9 | like | It is a slow, step by step exercise. But it's make us time to discuss the consequences of this way to work. Good! | ||
Z****-3 | like | Forces you to think actively about the development process | ||
Z****-3 | like | step by step test task. | ||
Z****-3 | like | this gives a nice new way of thinking about code writing | ||
Z****-3 | like | thinking about each test before writing code | ||
Z****-3 | like | shorts bursts of "feel good" moments... at least until the bugs arrive... iterative approach, small steps are beneficial | ||
Z****-3 | like | I like the concept that when using TDD, I can catch bugs early in the process and avoid a lot of future headaches. | ||
Z****-3 | like | I am not sure yet it was my first time coding this way. | ||
Z****-3 | like | good method of creating working regression tests. | ||
Z****-3 | like | Developing the tests before coding Moving the code development along with the test development | ||
Z****-3 | like | I like the aspect of discovery as we are writing test stubs and then coding to get the tests to pass. | ||
Z****-3 | like | Your example does a very good job of demonstrating the underlying idea of very short develop-test cycles. | ||
Z****-3 | like | Course material is clear and easy to follow. Well paced | ||
Z****-3 | like | It forces the creation of a set of unit regression tests. | ||
Z****-3 | like | The framework/method of development driven from test point of view. | ||
Z****-3 | like | When the development is complete, so is the unit test. Allows the developer to focus on only what is truly necessary to complete task. | ||
Z****-3 | like | the fact that once the testing is done, the coding is done. | ||
Z****-3 | like | Forces you to write better code. | ||
Z****-3 | like | Helps prevent defects later on which saves time and money. | ||
Z****-3 | like | It is a new concept very different from what i have done before, and i see the value on testing more out front. It will be a new challenge to get used to just write enough code to test. I a new required skill which presents a new challenge which i like | ||
Z****-3 | like | easy to find bugs via automated test | ||
Z****-4 | like | gave me a very clear direction as to what to do next and where to take the project. | ||
Z****-4 | like | It forces me to make sure the piece of code I'm working on is correct. | ||
Z****-4 | like | Refactoring, Easy to catch error | ||
Z****-4 | like | - incremental development of your code and test framework - ability to test your code for the full feature set when you make a change | ||
Z****-4 | like | It's an easy way to systematically write testable code. (Makes writing tests easier) | ||
Z****-4 | like | It forces requirements/interfaces to be well defined before implementations are written. | ||
Z****-4 | like | hey look, the tests are done now an I will know if something broke | ||
Z****-4 | like | I liked how my code was always being checked by previous tests as I was writing new tests and code. It allowed me to be sure that any new changes did not break older functionality. | ||
Z****-4 | like | Writing tests before the implementation enforces testing the requirements rather than the implementation. | ||
Z****-4 | like | I like the iterative development process. You know right away if your code works or not. | ||
Z****-4 | like | Helps you find the problem quickly since you are adding the logic in incremental way. | ||
Z****-4 | like | I liked being able to see what to do next | ||
Z****-4 | like | Give you confidence that the functions you write work properly | ||
Z****-5 | like | I like the insurance it gives you when making changes in the codebase. | ||
Z****-5 | like | finding bugs along the way. Helping me think through corner cases. Producing cleaner, or reliable code. | ||
Z****-5 | like | liked tackling one issue at a time & how the development feels guided | ||
Z****-5 | like | Interactive session | ||
Z****-5 | like | It forces you to think about the implementation piece by piece and ensure the code responsible works. | ||
Z****-5 | like | Getting the hang of adapting to what the tests req | ||
Z****-5 | like | it's good to catch errors and learn | ||
Z****-5 | like | Helped understand how good functionality can be created based on tests | ||
Z****-5 | like | It helps to catch bugs early. It also helps to make sure that you do not break your interface or implementation when changes are made. The tests live with the code and you get immediate feedback. | ||
Z****-5 | like | instant feedback | ||
Z****-5 | like | I enjoyed the instant feedback of knowing if the code was working (or not). | ||
Z****-5 | like | I liked the ability to try new code and quickly get feedback. | ||
Z****-5 | like | The anticipation of problems and consciously preparing for them | ||
Z****-5 | like | The incremental changes getting rapidly checked gives me more confidence that the final product will work (and what exactly I need help on to get fixed). | ||
Z****-5 | like | Root Beer. Getting to know the people around me. Preparation taken by instructor and the easy to follow hands-on experiment provided. The test harness is cool. Very powerful and facilitates creating and running the tests. | ||
Z**-1 | like | assurance | I like the assurance I get that my code is working properly | |
Z**-1 | like | clean | Encourages removal of cruft and unnecessary features | |
Z**-1 | like | Concreteness | In the absence of Dijkstra's mathematical proof, the approximation to a proof that your code is correct | |
Z**-1 | like | confidence | I liked the fact that for every line of code I wrote, it was confident that it worked because I wrote the unit tests simultaneously. | |
Z**-1 | like | confidence | I am able to gradually build something big step by step and I know for sure the part I tested will work. | |
Z**-1 | like | Confidence that my code works | hey hjey | |
Z**-1 | like | Confidence that my code works | a like | |
Z**-1 | like | Discipline | Practicing the mental habit of making a "hard" specification before writing the code | |
Z**-1 | like | driven-by-goals | can incrementally build towards requirements and desired features via tests | |
Z**-1 | like | driven-by-goals | can incrementally build towards goals and requirements via tests | |
Z**-1 | like | easier-tests | It was easier to think about tests that needed to be written. | |
Z**-1 | like | effortless | I ended up with a mostly well tested code, without thinking about testing it in post. | |
Z**-1 | like | failure | Ensuring the test fails is important - protects against poorly written or mis-targeted tests | |
Z**-1 | like | Feedback | Fast feedback from tests about what does and doesn't work in the implementation. | |
Z**-1 | like | feedback | I like that it provides quick feedback as I'm writing code. | |
Z**-1 | like | Find problems quickly | found bugs fast | |
Z**-1 | like | Find problems quickly | Getting stuff working | |
Z**-1 | like | High test coverage | kjhakj akjalkjakjakj dkfjsdfjksd | |
Z**-1 | like | Immediacy | The short time between writing something wrong (even in so trivial an example as a circular buffer) and finding the mistake. | |
Z**-1 | like | interesting | it's an interesting and different approach for solving a problem. | |
Z**-1 | like | minimal | I like that TDD seems to be a straightforward way to convert "requirements" into code. It also forces you to think of the simplest / minimal implementation. | |
Z**-1 | like | Other. | this and that | |
Z**-1 | like | Precision | The idea of finding a way to codify your class' behaviour before you write it | |
Z**-1 | like | prioritize | I like that it pushes writing tests to the forefront of your mind when programming, not just an afterthought. | |
Z**-1 | like | Proactive | Focus on testing upfront. | |
Z**-1 | like | solid | 1. Every line of code is tested. There is no untested code going into production. 2. All the code is testable, I don't need to refactor the code when trying to test it. | |
Z**-1 | like | structured | Linear, structured approach to code development. Less brainpower dedicated to tackling the whole problem. Rather it's just: test, fix issue, move on. | |
Z**-1 | like | Surprising | It enforces me to write comprehensive unit tests. It helps me formulate the characteristics that the unit should have before the design stage, so I can avoid mistakes as early as in the design stage. | |
Z**-1 | like | test-coverage | TDD results in small, well-tested units of code. Good tests and code coverage happen naturally. | |
Z**-1 | like | testthetests | I like that it "tests the tests" by ensuring they can fail. |
A blank page can be very intimidating, even for a Test-driven developer. Where do we start? Write a test, right? Not always.
more...Here is a short interview with James about TDD and embedded software from the deliver:Agile conference last spring.
more...Do you have some time to do a simple programming problem in C or C++ for my research?
more...My long-time good friend (Uncle) Bob Martin and I have fun programming together firing tracer bullets for distributed water pressure measurement system.
more...You can find a recording of the webinar presentation James Grenning gave with Jama Software on this page (once it is posted): Agile for Embedded -- Overview and Pitfalls.
more...James is the author of Test-Driven Development for Embedded C.
Have you read Test-Driven Development for Embedded C? Please write a review at
Amazon
or
Good Reads
.