What 1141 people liked about their first TDD experience

Course code Kind In a Word Impressions
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 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 self-regulating It makes the programming process rigorous and self-regulating. This prevent bugs from compounding and developing into massive bugs.
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 Systematic Methodical approach
B**-1 like Concise I like the idea of working on one problem at a time (small structured approach).
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 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 Systematic A systematic approach
B**-1 like validation validation will drive the implementation, not the other way around
B**-1 like modular The coding and logic manipulations. Forces modular implementation
B**-1 like Ahhummm This first exercise ran smoothly
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 Efficient A methodical process to build robust code and develop a based of test cases.
B***-11 like ease-of-use Seems to be relative easy to use once we get the hang of it.
B***-11 like minimalist I like the idea of not building anything more than what you are currently testing.
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 Incremental Incremental development so always testing and find bugs early
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 future-proof It can prevent working portions of the code from breaking
B***-12 like quick Quick feedback
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 Gamification It is satisfying to "solve" tests.
B***-12 like Efficiency I think TDD is enable the development quickly and efficiency.
B***-12 like feedback I like the fast feedback loop. You're compiling and running very quickly after you start.
B***-12 like Everything Everything.
B***-12 like methodical I like that the development process is very thorough, methodical, and structured.
B***-12 like Feedback Quickly able to verify changes didn't break previously working features.
B***-12 like instant Instant feedback if code is working
B***-12 like Confidence Having a large bank of tests is reassuring when making large changes.
B***-12 like feedback quick feedback when a change broke something
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 Fast feedback xxxx
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 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 Fun Allows for multiple refactoring without limits
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 Structured approach Let you build tests that you were confident in even if the implementation underneath was only half-cooked
B***-13 like Minimal implementation It was interesting, not having to figure out the entire data structure and interface first. Iterative.
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***-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 think Makes you stop and think about how your implementation will work before you actually implement it
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 harness I liked the harness driven approach. It is faster than debugging.
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 encourage I like the improved quality.
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 like Minimizing the number of changes between executions of the test which reduces the possible causes of the failures.
B***-1 like structured It's structured, that helps to detect errors earlier.
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 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 test...test forces you to test your implementation while you develop the interface for your code.
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 BLUE-1 BLUE-1 Test Comment
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***-2 like simplicity I like the iterative develop to get the smallest solution working.
B***-2 like warm fuzzies That your velocity increases as your body of written tests grows, and you get more warm fuzzies.
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 simple Clear, simple framework
B***-2 like Thorough The emphasis on failing early and often.The incremental approach to building tests.
B***-2 like Interfaces Forces you to specify out your interfaces early (pre- actually implementing them)
B***-2 like Finding defect early Finding defect early.
B***-2 like definitions It helped really define the class interface before actual implementation was required.
B***-2 like safer Feels safer to change code
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 iterative The iterative nature of TDD. For the most part, it allowed you to focus on smaller pieces of the code.
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 not as much overhead The process did get easier as the implementation became more complete.
C*****-2 like show I like having the tests to show me what's not working.
C*****-2 like iterative Helps to ingrain iterative development into oneself.
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 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 fulfilling Seeing progressive improvement was great. Able to execute my code without it being part of a larger component
C*****-2 like nothing nothing.
C*****-2 like simple it dosent take a lot of effort to make your code pass
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 loop I liked that the environment allowed for quickly running tests and seeing results.
C*****-2 like validation It is great seeing confirmation that the code you're writing is working as you're writing it.
C*****-2 like unbiased Testing is considered upfront before any code is written.
C*****-2 like tricking tests The exercise we performed demonstrated the importance of writing test sets that can't be tricked into passing.
C**-1 like increments Small increments are easier to manage
C**-1 like peace of mind Having confidence that my code is somewhat tested
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 straightforward It is a more straightforward/mechanic method to develop
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 incremental It's methodical, with only small changes made with each cycle
C**-1 like Testability Makes you think about development step by step and each part is proven with a new test.
C**-1 like effort Forces you to think about developing in a different, initially less comfortable way.
C**-1 like code overview Force me to rethink what I have implemented.
C**-1 like positive feels like you can make significant progress without completing much functionality
C**-1 like accomplishment gives you sense of accomplishment.
C**-1 like tests Tests are present for functionality.
C**-1 like procrastination it is OK to be a 'lazy' programmer, and procrastinate until you are forced to.
C**-1 like mistakes Experiencing mistakes I do in coding, like wrong checking
C**-1 like agile The concept of devloping and testing in small increments, its like Agile, aka iterative waterfall :)
C**-1 like deterministic converts hidden test and debugging time into actual measurable (and very long) deterministic development/ testing time
C**-1 like refactoring Helps with refactoring.
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 breaks down the problem. Enforces incremental development. Ensure that new features do not break existing ones.
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 progressive I liked that it was testing chronological building blocks. Building into larger more complete pieces of code.
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 - 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 High test coverage Sure not to develop unused code
C****-25 like Fast feedback Nice modular work.
C****-25 like Fast feedback Very fast feedback loop code->testing
C****-25 like Minimal implementation forces you to get to the minimum complexity to meet requirements (expressed by tests)
C****-25 like Fast feedback simple and quite straight forward
C****-25 like Structured approach Code driven by interface
C****-25 like Structured approach it makes clearer the requirements.
C****-25 like Find problems quickly Incrementally driving code with tests helps to find issues quickly.
C****-25 like Confidence that my code works Thinking about production code incrementally
C****-25 like Fun Its very fun
C****-25 like High test coverage Trying out a different development style than what I am used to.
C****-25 like Fast feedback it forces us to think about every step of code development
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 Fun We get to write code, that's small fun and easy
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 Confidence that my code works The functions you write might have surprising behavior and the test helps to identify it
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****-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 All the above. Instant feedback with checks for memory leaks enabled.
C****-25 like Fast feedback Writing code incrementally; it made identifying errors easier.
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 simple I liked the incremental approach.
D****-2 like FixFast I like the short time between failure through diagnosis to fix.
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 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 usefull It catches design problems and logical errors early before they become baked into the code
D****-2 like focus Helps frame the design by forcing to focus on one detail at a time.
D****-2 like Oversight TDD help prevent creating undetected bugs in existing code when making modifications or refactoring.
D****-2 like short failures That there are only short intervals of being in a state of not-working.
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 incremental small incremental progress in the right direction == good
D****-2 like confidence refactoring with confidence from known working code and test == good
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 Strong Very simple. Easy for understand
F**-1 like careful It helps me think more careful about my code
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 Easier Just easier to debug and check my function. It helps me to be carefully to write code.
F**-1 like workflow The course will teach people how to perform unit test, integrated test, system test.
F**-1 like think corner cases We can think about corner cases before writing code
F**-1 like amazing Help me to have a mindset on how to test code during development
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 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 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 Wow Should think about the system before start writing code. write and test continuously.
F**-1 like average Make me think more carefully during the coding process. But it takes time to get familiar with.
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
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
L*-4 like error proof? avoid chance to make mistake, errors
L*-4 like coding I like change signal red or yellow to green (coding with test)
L*-4 like proof I can get each line of code tested.
L*-4 like step by step I can develop step by step more logically.
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 Stable If test code gets well made, it looks we can make really stable S/W at the first time.
L*-4 like Satisfaction TDD makes me feel some satisfaction and progress.
L*-4 like in progressive I liked that I can make the code in progressive from zero to hero.
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 makeing test code I like making test code. it's a effective experience.
L*-4 like safe code I got the feeling of building up the code.
L*-4 like concentration I can focus on each test step when writing codes.
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 immediatly check error case & handle it immediately.
L*-4 like separated Complex implementations can be simply separated.
L*-4 like automated Get automated test results for changed code
L*-4 like passes I liked making code to pass the test, even though the test was simple.
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
L*-4 like Feedback responsive , feedback
L*-4 like Basic It reminds me "Back to Basic"
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 avoid bugs I can reduce the chance of creating bugs.
L*-4 like avoid bugs I can reduce the chance of creating bugs.
M***-1 like coverage Easy way to get full functional 'coverage'
M***-1 like Correction Checks all the input conditions for the functions.
M***-1 like Simplicity 1 Thing at a time
M***-1 like structured It forces you to create the API functions early in the process
M***-1 like small I like that it forces you to implement the code step by step, with small increments.
M***-1 like Simplicity forced to focus on one thing at a time
M***-1 like requirements I like that you can map requirements to code more easily.
M***-1 like coverage All possible situations are tested
M***-1 like way to go helps to make code more robust
M***-1 like small step software problem are divided is many smaller problem that are more easier to fix.
M***-1 like architecture Test driven architecture: The architecture of your code becomes testable and arguably better
M***-1 like small steps its breaking up development into small steps
M***-1 like collaboration collaboration and support
M***-1 like Function it seems to force you to really think about the function and responsibilities of parts of the code
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 Fast feedback hey what are you saying
N***-1 like Find problems quickly this is a test
N***-1 like Find problems quickly Catching errors quickly
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 Structured approach The code came together well at the end and you know it's decent code because it was tested
N***-1 like Find problems quickly Small changes let you find the problems quickly.
N***-1 like Other. Helps to find small bugs like typos right off the bat.
N***-1 like Fast feedback I like the building up of the design based on passing small tests for behavior.
N***-1 like Structured approach Very methodical and thought process is traceable assuming we use version control for intermediate checkins.
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 High test coverage I like being told what parts of my code are not covered by tests
N***-1 like Confidence that my code works I like being confident that my code works
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 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 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"
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 everything what;'s not to like. some other stuff, and even more now. now what. and another line And then some
T***-1 like 851 like 851 -- revised, again, and once more
T***-1 like this this and that
T**-1 like feedback Quick feedback for both my successes and failures.
T**-1 like Piecemeal Forces you to think in little (testable) pieces
T**-1 like Unsure I don't know enough to know what I like about it just yet.
T**-1 like good good overview enjoyed the practical so far
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 flow Good work flow (write tests first, build on-top of tests).
T**-1 like simple Can concentrate on very small functionality at a time.
T**-1 like co-development Encourages thinking about how code should be tested while developing
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 working The ability to keep code working.
T**-1 like forced perspective I enjoyed the minimal development approach. It forced me to adopt another perspective for debugging
T**-1 like language Not a new language to learn, more or less
U**-1 like Minimal implementation Not need to focus on the entire problem at once.
U**-1 like High test coverage It forces you to test every line of code.
U**-1 like Fast feedback simple approach to breaking down a problem
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 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 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 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 Fun It is more interactive.
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 Find problems quickly I like find bug when I change code
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 Find problems quickly I like find bug when I change code
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 Find problems quickly I like find bug when I change code
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
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 like incremental development. validate, test, necessity of a , need for variables in microscopic details. emphasis on code coverage
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 Helps Helps you catch bugs early on
V****-2 like easier testing Made testing code easier.
V****-2 like interesting It gave me an idea of how to write fewer bugs in my code.
V****-2 like incremental Made inclemently implementing features easier.
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 Quality Quick feedback loop when implementing -> continuous improvement.
V**-1 like iterativ fast feedback with small changes
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 control More control on production code
V**-1 like Feedback Fast feedback. It's rewarding to get lots of successes
V**-1 like time saving saves time otherwise spent debugging
V**-1 like Progress The instant feedback of progress.
V**-1 like Traceable it is easier to trace where we went wrong in the code. and took less time to fix it.
V**-1 like iterative The iterative approach to tested when done
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 Expectation You tend to think more about the expected outcome before make changes.
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 consistent behavior It helps to secure that existing code works when making changes or refactoring.
V**-1 like efficient The quick feedback about our code.
V**-1 like Structure Enforces you to not add unnecessary code -> adds structure to the process of implementation.
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 Confidence Creates confidence about the code being developed.
V**-1 like New Learning a new development approah, writing a test before writing the implementation.
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 Feels confident Gives enough satisfaction about the code written.
V**-1 like safety net easy to change without risk of breaking something
V**-1 like done Tests are done when you are.
V**-1 like Amazing The training is amazing! I like the learning method (nice presentation + practical excercies) to understand TDD better
V**-1 like Easy TDD is much easier than I tought.
V**-1 like Rewarding It is rewarding to see the result immediately (not so rewarding when breaking a test ;-) )
V**-1 like FewerBugs It is easy to trace
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 incremental Incremental progress.
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 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 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**-18 like interesting Its an interesting way to test software. Which is a new experience for me.
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 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 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 intriguing Gave me a new perspective on Software development.
W**-19 like methodical Very methodical. I liked slowly working through all the implementation details through specific tests.
W**-19 like Instant Feedback Instant feedback if code is broken.
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 different Provides a different way to view development.
W**-19 like Confidence TDD gives you confidence about your code.
W**-19 like Task Creation Breaking down a large task into multiple smaller tasks
W**-19 like Memory Reminds you where you are on a task if you get distracted
W**-19 like Test Coverage The test coverage you're left with once complete.
W**-19 like Automation Testing is done for you.
W**-20 like reliable I like that you test as you go and so your code is more reliable.
W**-20 like lego Short iteration with short implementation. You get more understanding of the code that you write.
W**-20 like regularity I like the regularity of the steps: do the same process, one bit at a time
W**-20 like bite-sized Small steps: I like that each step is small, minimizing cognitive load
W**-20 like safety-net I like how the tests seem to "lock in" the behavior as you go along
W**-20 like methodical The ability to test along the way ... takes care of the unit testing
W**-21 like small steps Like that it forces small steps
W**-21 like feedback I like building up quick wins. I know I'm making progress.
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**-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 guidance TDD guides you to a clean interface and minimal implementation.
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 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 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 mindset change Fail early, fix quickly
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 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 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 Good Approach I like the approach of the TDD training session
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 effortless I ended up with a mostly well tested code, without thinking about testing it in post.
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 Proactive Focus on testing upfront.
Z**-1 like Feedback Fast feedback from tests about what does and doesn't work in the implementation.
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 interesting it's an interesting and different approach for solving a problem.
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 easier-tests It was easier to think about tests that needed to be written.
Z**-1 like Precision The idea of finding a way to codify your class' behaviour before you write it
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 prioritize I like that it pushes writing tests to the forefront of your mind when programming, not just an afterthought.
Z**-1 like Discipline Practicing the mental habit of making a "hard" specification before writing the code
Z**-1 like testthetests I like that it "tests the tests" by ensuring they can fail.
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 feedback I like that it provides quick feedback as I'm writing code.
Z**-1 like driven-by-goals can incrementally build towards requirements and desired features via tests
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 failure Ensuring the test fails is important - protects against poorly written or mis-targeted tests
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 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 test-coverage TDD results in small, well-tested units of code. Good tests and code coverage happen naturally.
Z**-1 like driven-by-goals can incrementally build towards goals and requirements via tests
Z**-1 like clean Encourages removal of cruft and unnecessary features
Z**-1 like High test coverage kjhakj akjalkjakjakj dkfjsdfjksd
Z**-1 like Other. this and that
Z**-1 like Confidence that my code works hey hjey
Z**-1 like Find problems quickly found bugs fast
Z**-1 like Find problems quickly Getting stuff working
Z**-1 like Confidence that my code works a like

Make this into a word cloud

Select text below (triple click), copy, then try one of these tag cloud generators
jasondavies word cloud generator - colorful
tagcrowd - lets you show counts