What 1028 people liked about their first TDD experience

Course code Summary selected Impressions
C*****-2 like: "secure" I liked that everything is supposed to be and keep working regarding the continuous requirements on the way to MVP
T***-1 like: 851 like 851 -- revised, again, and once more
C**-1 like: accomplishment gives you sense of accomplishment.
C**-1 like: agile The concept of devloping and testing in small increments, its like Agile, aka iterative waterfall :)
B**-1 like: Ahhummm This first exercise ran smoothly
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.
C****-25 like: All the above. Instant feedback with checks for memory leaks enabled.
C**-1 like: All the above. Hands on exercise is useful
C**-1 like: All the above. I like the fact that we need to write enough code to just pass a failing test. And along the way tool does find overshooting (writing extra code than required for passing a test) based on coverage.
C**-1 like: All the above. Iteratively and incrementally the solution evolves.
E***-1 like: All the above. - 100% test coverage achieved automatically - interface written from user perspective - no feature creep
E***-1 like: All the above. - TDD forces a structured buildup of your implementation - When done right, it results in 100% code coverage
E***-1 like: All the above. I like that the code grows organically and all paths are tested and no unneeded code is written.
H***-1 like: All the above. It is a one step at a time. When ever a new code added it insures it doesn't break the previous implementation.
H***-1 like: All the above. Pretty much interesting and worth putting the effort to write a better, less bug-prone code before testing it! Liked the modular approach to constructing the code based on test-cases.
H***-1 like: All the above. Good coverage. Easily identify issues.
H***-1 like: All the above. Structural Approach. One step at a time
H**-1 like: All the above. I like the flow of TDD. Small incremental steps.
H**-1 like: All the above. I like being able to see pitfalls in my code by my previous tests. Being able to see how my code has adapted to fit a current need, but also allows me to know what mistakes I have made.
I**-1 like: All the above. cooperation with Ivo :)
I**-1 like: All the above. color icon
L***-1 like: All the above. I can see how the code written is really what you want it to do.
M***-1 like: All the above. DEMO
M***-1 like: All the above. problems can split down to smaller pieces which is easier to focus and get things done
M***-2 like: All the above. It was an interesting start, the Handson was good, The trainer was very approachable, He also briefed the session very clearly with live coding exercise.
M***-2 like: All the above. It help to find bugs at very early phase of development.
M***-2 like: All the above. It help to find bugs at very early phase of development.
M***-2 like: All the above. Writing a test before the production code makes the development and testing go in parallel so that there are no bugs identified at later stages in the development.
M***-2 like: All the above. Writing a test before the production code makes the development and testing go in parallel so that there are no bugs identified at later stages in the development.
M***-2 like: All the above. It helped me to be more structured & tackle the big problems by one step at a time approach.
M***-2 like: All the above. I like the approach to move from simple to complex step by step
M***-2 like: All the above. Structured approach Towards Programming which starts from designing Test cases first and then implement in a faster and confident manner covering most scenarios.
M***-2 like: All the above. switching between test mind set and development mind set
M***-2 like: All the above. I like that, TDD give understanding that, we can test the code at early stage of development.
M***-1 like: All the above. I like that it preserves testing for behavior that you've previously implemented, so you can immediately determine if your incremental changes broke existing functionality
M**-2 like: All the above. It is a step by step process to develop and test code.
N***-2 like: All the above. With TDD, we can detect bugs in our code if any at earliest stage of the development, and fix those then and there. Also we can think of all the corner cases while writing different test cases.
N**-2 like: All the above. I liked the immediate feedback and focus on the code as it is being written.
R**-1 like: All the above. It makes absolutely sure the code I write is testable. It makes absolutely sure I have tests. It makes it easy to add regression tests later.
R**-1 like: All the above. TDD helps you to avoids errors already during implementation.
R**-1 like: All the above. I enjoy exercices
R**-3 like: All the above. Seeing code and tests evolve together
R**-3 like: All the above. Another method of writing code.
S***-1 like: All the above. It makes you focus on one thing at a time.
N/A like: All the above. I liked that a data structure useful in real life was developed instead of developing some trivial toy code.
N/A like: All the above. The low barrier to entry and the fact that it's somewhat self-documenting.
N/A like: All the above. I like that it quickly helps hash out the interfaces and prevents simple errors.
U**-1 like: All the above. Easy to use and clear evolution of the testing regime as you progress. Encourages revisiting of previous work to improve test coverage.
U**-1 like: All the above. The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this
U**-1 like: All the above. I liked the modularity, the step by step programming. I liked also how easy is to make in code something you have in mind. It like a guided procedure
U**-1 like: All the above. The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this
U**-1 like: All the above. The incremental development is natural way we develop software and the SW requirements also keeps on changing as the product evolves. TDD seems to be right approach for this
W**-24 like: All the above. Being in the flow, quick feedback, reduced cognitive load.
W**-25 like: All the above. starting with test cases before designing and implementing is interesting and the experience is new to me
W**-26 like: All the above. easy to focus one thing
W**-27 like: All the above. Its very simple yet can help spot nasty bugs early. Its quick.
W**-27 like: All the above. I selected all the above. However this is great for a code written from scratch. Wondering how can we use it when we add few lines on a pile of code that function doesn't have an unit test.
W**-30 like: All the above. That the previous tests where able to find bugs in the code. That I feel more sure that bugs due to my big changes will be find by my tests.
W**-32 like: All the above. Very efficient use of time. Nice quick way to start implementing a design without overthinking it.
W**-32 like: All the above. Developing in short cycles to add one small capability at a time. Having tests for all previously introduced capability gave me confidence that regressions would be quickly discovered.
W**-32 like: All the above. I like the focus on a smaller problem first. Kinda like putting a puzzle together
W**-33 like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
W**-33 like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
W**-33 like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
W**-33 like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
W**-34 like: All the above. Testing documents the API, the parameters and the usage of the module.
W**-34 like: All the above. At each step I feel that the job is done. I only go forward. I can finally breath when I stop to lunch!
W**-35 like: All the above. I really like, the simplicity and efficiency. It barely takes times to correct an error. Fast feedback.
W**-35 like: All the above. locking the functional behaviour and incremental development approach
W**-35 like: All the above. Very practical, and fun.
W**-36 like: All the above. Writing tests first and forcing you to slow down. Prevents you from getting ahead of yourself.
W**-36 like: All the above. *Tests document use. *You create your own regressions as you go. *You can write code with more confidence - if you ever break anything, a test should catch it. *Refactoring is easier.
W**-36 like: All the above. The way I read it, the TDD takes more efforts and time to develop codes, but it minimizes the risks, failures and the time for debugging and fixing issues for development in a long run.
W**-36 like: All the above. I liked how the code was written in thoughtful, tested increments that forces me to consider the implementation and how it relates to previous tests.
W**-36 like: All the above. Eveything you want the code to do has a test, and nothing more nor less. The tests take seconds to run! There is no fear of refactoring.
W**-37 like: All the above. I liked small incremental steps which enabled feeling of accomplishment. Also progressing the CB development had a safety net which indicated problems early on.
W**-38 like: All the above. I like how it forces you to define expected behavior before implementing actual code. It's really easy to write code without thinking about what you actually want it to do. TDD helps prevent that.
W**-38 like: All the above. Systematic, methodical, pragmatic, safe progress
W**-38 like: All the above. Systematic, methodical, pragmatic, safe progress
W**-38 like: All the above. I learned how to think in incremental steps to push writing code. Starting with small units that pass helps build momentum. I learned how to update previous unit tests as more complex code is written.
W**-39 like: All the above. I like to keep mastering my code behaviour while gaining the freedom to refactor it at will
W**-39 like: All the above. I like to keep mastering my code behaviour while gaining the freedom to refactor it at will
W**-40 like: All the above. I really liked that tests spotted breaking changes and that the logic behind the code built up in small and understandable increments
W**-40 like: All the above. I like the flow of the TDD cycle, the constantly testing the code makes me confident that I'm progressing in the right direction and not breaking anything on the way. :-)
W**-40 like: All the above. Easier to find out what are the next steps.
W**-41 like: All the above. Test cases are written before write the code, test are simples and makes less bug in code.
W**-41 like: All the above. I like wingman-sw.com interface very understandable.Also gather.town has good feature!TDD is good!I didn't think about final production code because it happened automatically when you pass tests!
F**-1 like: amazing Help me to have a mindset on how to test code during development
V**-1 like: Amazing The training is amazing! I like the learning method (nice presentation + practical excercies) to understand TDD better
M***-1 like: architecture Test driven architecture: The architecture of your code becomes testable and arguably better
Z**-1 like: assurance I like the assurance I get that my code is working properly
L*-4 like: automated Get automated test results for changed code
W**-19 like: Automation Testing is done for you.
F**-1 like: average Make me think more carefully during the coding process. But it takes time to get familiar with.
L*-4 like: avoid bugs I can reduce the chance of creating bugs.
L*-4 like: avoid bugs I can reduce the chance of creating bugs.
L*-4 like: Basic It reminds me "Back to Basic"
W**-20 like: bite-sized Small steps: I like that each step is small, minimizing cognitive load
B***-1 like: BLUE-1 BLUE-1 Test Comment
F**-1 like: careful It helps me think more careful about my code
Z**-1 like: clean Encourages removal of cruft and unnecessary features
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.
T**-1 like: co-development Encourages thinking about how code should be tested while developing
C**-1 like: code overview Force me to rethink what I have implemented.
L*-4 like: coding I like change signal red or yellow to green (coding with test)
M***-1 like: collaboration collaboration and support
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.
L*-4 like: concentration I can focus on each test step when writing codes.
B**-1 like: Concise I like the idea of working on one problem at a time (small structured approach).
Z**-1 like: Concreteness In the absence of Dijkstra's mathematical proof, the approximation to a proof that your code is correct
B**-1 like: confidence I like that I can be confident that new changes haven't broken functionality that has already been tested.
B***-12 like: Confidence Having a large bank of tests is reassuring when making large changes.
D****-2 like: Confidence I feel more confident that my software is fully functional when I have a suite of tests that pass.
D****-2 like: confidence refactoring with confidence from known working code and test == good
V**-1 like: Confidence TDD helps when writing the code and I feel more confident when I deliver the code. The real benefit I think is later - the code stays tested over time.
V**-1 like: Confidence Creates confidence about the code being developed.
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**-19 like: confidence You can add new features with more confidence that prior functionality will not get broken, since your old tests continue to pass
W**-19 like: Confidence TDD gives you confidence about your code.
Z**-1 like: confidence I liked the fact that for every line of code I wrote, it was confident that it worked because I wrote the unit tests simultaneously.
Z**-1 like: confidence I am able to gradually build something big step by step and I know for sure the part I tested will work.
A**-1 like: Confidence that my code works It makes sure that every line you write is tested
A**-1 like: Confidence that my code works While you progress, you can check that the basic functionality that you already programmed didn't break.
A**-1 like: Confidence that my code works I liked creating code increasing its complexity
A*-1 like: Confidence that my code works Easy to test that the code you've written works
A*-1 like: Confidence that my code works Refactoring. See the tests pass.
A*-1 like: Confidence that my code works Easy to test code without hw. Forces you to create a properly defined interface
A*-1 like: Confidence that my code works Forces focus on interface and gives you coverage on refactoring
A*-1 like: Confidence that my code works Forces focus on interface and gives you coverage on refactoring
A*-1 like: Confidence that my code works Focus on testability of design
A*-2 like: Confidence that my code works Don't need to think about what is happening, it's almost a no-brainer activity when wondering "does my code work?" IF adhering to TDD properly.
A*-2 like: Confidence that my code works That we can be sure the code we write do exactly what was intended, and the fact that it forces us to implement smaller functions and cleaner code.
B***-13 like: Confidence that my code works Positive affirmation that was is expected is delivered.
B***-13 like: Confidence that my code works Made me confident to change my code
B***-13 like: Confidence that my code works The moment where we had to refactor to get circular looping working felt less stressful since I had the tests to confirm I did break anything that was already working.
B***-13 like: Confidence that my code works The unit tests make it easy to document the thought process of what is expected of the code under test.
C****-25 like: Confidence that my code works Thinking about production code incrementally
C****-25 like: Confidence that my code works The functions you write might have surprising behavior and the test helps to identify it
C**-1 like: Confidence that my code works I like that TDD encourages breaking up a problem into very small steps that makes it easier to come up with a resilient solution.
H***-1 like: Confidence that my code works It helps to incrementally proceed with the logic implementation . And helps to adress new usecases as we proceed.
H***-1 like: Confidence that my code works It helps to incrementally proceed with the logic implementation . And helps to adress new usecases as we proceed.
H***-1 like: Confidence that my code works Breaking down the requirements made it easy to implement the logic
H***-1 like: Confidence that my code works It catches regression errors
H***-1 like: Confidence that my code works best part of it is you develop a new feature with the test you already know if any previous feature is broken, and hence the final product will not surprise you
H***-1 like: Confidence that my code works It is iterative and gives opportunity to find bugs
H***-1 like: Confidence that my code works TDD is finding bugs early and we can rework our code without worrying about introducing new bugs
H***-1 like: Confidence that my code works reduces chances of bugs and the need to write unit tests later just for the sake of satisfying quality audits
H***-1 like: Confidence that my code works It is very good experience for me. Actually it is first time to hear the TDD, and I think it will help developers to improve their coding from test perspective.
H***-1 like: Confidence that my code works writing tests as your write code, results is less defects later.
H***-1 like: Confidence that my code works writing tests as your write code, results is less defects later.
H**-1 like: Confidence that my code works I felt like I knew what was going on exactly at each step as opposed to assuming things will work. Its reassuring to know your code is going to work
H**-1 like: Confidence that my code works like like
I**-1 like: Confidence that my code works I feel more confident to refactor / optimize the tested class
I**-1 like: Confidence that my code works I liked the fact that the code is easier to be maintained and refactored
I**-1 like: Confidence that my code works I like that TDD teaches us to take time to write very small steps of incremental coding. I believe it significantly reduces the risk of bugs by moving small steps at a time
J***-1 like: Confidence that my code works Greater confidence that my code works as expected.
J***-1 like: Confidence that my code works Provides immediate indication if your tests are being passed or if you broke a previous test.
J***-1 like: Confidence that my code works Minimize future issues.
M***-1 like: Confidence that my code works Great exercise to understand how to build up a test driven design.
M***-1 like: Confidence that my code works easier to troubleshoot. feel confident to re-structure the code.
M***-2 like: Confidence that my code works High test coverage
M***-2 like: Confidence that my code works High test coverage
M***-2 like: Confidence that my code works New experience, never had idea we can write test first before we implement the code.
M***-1 like: Confidence that my code works Having the test suite at the end to provide a safety net when refactoring code.
M***-1 like: Confidence that my code works I liked the increased confidence in my production code and the safety net for refactoring
M***-1 like: Confidence that my code works I like being able to break the problem down into smaller pieces.
M***-1 like: Confidence that my code works TDD gives me more confidence about my code. TDD helps me to think different test cases while i start working on my way to test.
M**-1 like: Confidence that my code works Refactoring code is much easier when you have good test coverage, as you can make changes freely without worrying about breaking something without realising it.
M**-1 like: Confidence that my code works It helps to test code properly.
M**-2 like: Confidence that my code works It makes you think ahead and helps to eliminate missing little mistakes. And the incremental development allows you to have confidence in previous code before moving on.
M**-2 like: Confidence that my code works It makes you think ahead and helps to eliminate missing little mistakes. And the incremental development allows you to have confidence in previous code before moving on.
M**-2 like: Confidence that my code works It forces me to double check my logic and ensure fatal mistakes aren't introduced early on.
M**-2 like: Confidence that my code works You end up with the safety net of thorough unit tests for future refactoring and major changes as well.
N/A like: Confidence that my code works * Building in small increments * Confidence your code is behaving as expected as you move forward
N/A like: Confidence that my code works Having to verify that the test fails before you right code so you know that your code makes a difference when the test passes.
N***-1 like: Confidence that my code works Well tested code. Tests written can be reused for automation testing. Relatively simple at first.
N***-1 like: Confidence that my code works I like being confident that my code works
N**-2 like: Confidence that my code works Interactive and live environment to build as we go...
N**-2 like: Confidence that my code works Felt safe refactoring when I needed to go back and change something.
R**-1 like: Confidence that my code works Verifying code on the go made me confident about it. I am pretty sure the code I have made is working
R**-1 like: Confidence that my code works It is an excellent tool for refactoring.
R**-2 like: Confidence that my code works caring about bugs before programming the code makes me feel safe.
R**-3 like: Confidence that my code works I liked the step by step creation of the circular buffer. This gives me the security to have the feeling the buffer is working properly (esp. on boundary conditions).
R**-3 like: Confidence that my code works We feel safe while implementing the functionalities or refactor the code.
R**-3 like: Confidence that my code works I'm inform when I break something I have the feeling I can go fast I'm happy when it passed I'm confident about what has been done.
S***-1 like: Confidence that my code works Gives more initial confidence of code and tests. I also enjoy breaking the code and tests several times, before moving onto further development. It fulfills my violent urges.
N/A like: Confidence that my code works Yeah, I like it because I will not only have fewer bugs, but it also helps me make changes to my codes more confidently.
N/A like: Confidence that my code works I like that small increments are known to work before moving on to additional functionality, and indication that my changes did not "break" previously working code.
T*-1 like: Confidence that my code works - Tests are clearly designed and explained.
T*-1 like: Confidence that my code works All functionality realized is covered by tests. So if you get green you know, that any functionality covered by tests is guaranteed to work.
T*-2 like: Confidence that my code works once you have tc establishes it gives confidence that "I did not broke it" and it takes the fear to change something because you do not know yet what will happen - tcs will tell you.
U**-1 like: Confidence that my code works Didn't need to try and solve the whole problem at once. Incrementally built solution as added tests by refactoring code.
U**-1 like: Confidence that my code works It designs the tests ahead of the code.
U**-1 like: Confidence that my code works I can use it to progress in controlled manner so that I'm forced to think about what I'm doing
U**-1 like: Confidence that my code works Confidence that new code won't break the behaviour already done.
U**-1 like: Confidence that my code works Being able to focus on one small thing at a time when writing new code. Knowing that the test will catch issues when I make a change later.
U**-1 like: Confidence that my code works Being able to focus on one small thing at a time when writing new code. Knowing that the test will catch issues when I make a change later.
W**-22 like: Confidence that my code works I enjoy taking the small steps to make sure the code is correct, both test code and run code
W**-22 like: Confidence that my code works I like the exercise. I like the process of making the test fail first then pass. I also like the fact that back tests protect future code development.
W**-23 like: Confidence that my code works Never being very far from code that works.
W**-23 like: Confidence that my code works It gets a designer to think a little harder about implications of a line of code
W**-23 like: Confidence that my code works I like the feedback the tests provides when refactoring the code
W**-23 like: Confidence that my code works It's easy to play around with alternative implementations without starting from scratch.
W**-24 like: Confidence that my code works Building on past success
W**-24 like: Confidence that my code works Able to validate code as it is written.
W**-24 like: Confidence that my code works The guarantee that the behavior of previous tests is still in the code
W**-24 like: Confidence that my code works I like being able to make change without being afraid about breaking something in the process. (Like when we change the buffer from static to dynamic allocation.)
W**-25 like: Confidence that my code works I liked that my code told me when I broke it
W**-25 like: Confidence that my code works Mandates me to write unit test if I use TDD approach
W**-25 like: Confidence that my code works When modifying previous code, less fear of breaking already testable behavior.
W**-25 like: Confidence that my code works We write expected behavior (test) along with our code and verify that expectation is met as we write code.
W**-26 like: Confidence that my code works I like that after making changes to the heart of the code, the old tests provide me confidence I didn't break anything.
W**-28 like: Confidence that my code works TDD emphasizes the importance of tests as much as the importance of code.
W**-28 like: Confidence that my code works I liked that tests were built along with the code. There was less worry about refactoring or adding something would break existing code.
W**-28 like: Confidence that my code works Refactoring an implementation detail and knowing that nothing existing broke is great
W**-28 like: Confidence that my code works I like that in then end there will be a fully functional test to go along with code
W**-29 like: Confidence that my code works I had a safety net when refactoring
W**-30 like: Confidence that my code works The safety net
W**-30 like: Confidence that my code works That the code is fully tested when you go to release it.
W**-31 like: Confidence that my code works it is helpful to know that as I make changes to my code, all the previous code is still being tested.
W**-31 like: Confidence that my code works The tests verify that the code works.
W**-32 like: Confidence that my code works The safety net. It's like a latching system where every time I make progress, it's locked in by the tests... If it breaks I can just undo.
W**-32 like: Confidence that my code works Nice to see the details.
W**-34 like: Confidence that my code works i like how it makes you think of all the test cases of things that might go wrong and then gives you confidence that you're covering those test cases
W**-34 like: Confidence that my code works The ability to continue testing new code, with the previous tests running every run.
W**-34 like: Confidence that my code works It feels like I'm experiencing programming for the first time. It's the same sensation of power!
W**-35 like: Confidence that my code works Being sure that the code written before is still working as expected. That all specified edge cases are tested with every build/test run.
W**-35 like: Confidence that my code works The requirements must be understood before you write tests.
W**-35 like: Confidence that my code works I liked how the functionality increased and i was always sure that what we did still works.
W**-37 like: Confidence that my code works Forces a deterministic methodology for developing robust software.
W**-37 like: Confidence that my code works - I felt reasonably confident that the code still worked after a significant refactor - Helped stay away from pre-optimization - Encouraged finding the simplist implementation
W**-37 like: Confidence that my code works Safety net when changing code. Iterative process where you get to fully functional code. You do not need to think about every edge case while creating function, you get there step by step.
W**-37 like: Confidence that my code works I like the fact that tests stays and everything gets retested every time you refactor or add new features
W**-37 like: Confidence that my code works Guides the development clearly Satisfying seeing tests pass Previous tests can fail when implementation changes so prevents regressions
W**-38 like: Confidence that my code works - Knowing exactly what functionality is implemented, what's not - Little to no time spent debugging - Well tested building blocks that can be used for future functionality with confidence
W**-39 like: Confidence that my code works Many serious, hard-to/debug, bugs can be avoided if done correctly
W**-39 like: Confidence that my code works Many serious, hard-to/debug, bugs can be avoided if done correctly
W**-40 like: Confidence that my code works Ability to refactor with a "safety net."
W**-40 like: Confidence that my code works I liked that it makes you think about the code that you write. You have to plan for what you expect to happen before you write the code. Then you get feedback right away if it's wrong.
W**-40 like: Confidence that my code works I liked that it makes you think about the code that you write. You have to plan for what you expect to happen before you write the code. Then you get feedback right away if it's wrong.
W**-40 like: Confidence that my code works Mistakes are found immediately. We have to think about the failure conditions up front. Each step is taken with confidence.
W**-40 like: Confidence that my code works Writing the test first and then the function makes it clearer about the function's purpose
W**-40 like: Confidence that my code works Writing the test first and then the function makes it clearer about the function's purpose
W**-40 like: Confidence that my code works Write minimum code just to pass the test.
W**-41 like: Confidence that my code works It forces you to think a different way of programing. Go step by step (fail and pass)
Z**-1 like: Confidence that my code works hey hjey
Z**-1 like: Confidence that my code works a like
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.
V**-1 like: consistent behavior It helps to secure that existing code works when making changes or refactoring.
V**-1 like: control More control on production code
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.
M***-1 like: Correction Checks all the input conditions for the functions.
M***-1 like: coverage Easy way to get full functional 'coverage'
M***-1 like: coverage All possible situations are tested
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
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.
B***-2 like: definitions It helped really define the class interface before actual implementation was required.
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.
C**-1 like: deterministic converts hidden test and debugging time into actual measurable (and very long) deterministic development/ testing time
W**-19 like: different Provides a different way to view development.
Z**-1 like: Discipline Practicing the mental habit of making a "hard" specification before writing the code
V**-1 like: done Tests are done when you are.
Z**-1 like: driven-by-goals can incrementally build towards requirements and desired features via tests
Z**-1 like: driven-by-goals can incrementally build towards goals and requirements via tests
B***-11 like: ease-of-use Seems to be relative easy to use once we get the hang of it.
F**-1 like: Easier Just easier to debug and check my function. It helps me to be carefully to write code.
V****-2 like: easier testing Made testing code easier.
Z**-1 like: easier-tests It was easier to think about tests that needed to be written.
V**-1 like: Easy TDD is much easier than I tought.
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.
B***-12 like: Efficiency I think TDD is enable the development quickly and efficiency.
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***-11 like: Efficient A methodical process to build robust code and develop a based of test cases.
V**-1 like: efficient The quick feedback about our code.
C**-1 like: effort Forces you to think about developing in a different, initially less comfortable way.
Z**-1 like: effortless I ended up with a mostly well tested code, without thinking about testing it in post.
B***-1 like: encourage I like the improved quality.
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.
L*-4 like: error proof? avoid chance to make mistake, errors
B***-12 like: Everything Everything.
T***-1 like: everything what;'s not to like. some other stuff, and even more now. now what. and another line And then some
W**-21 like: exceute I like the way of writing our own test cases to check the code
B**-1 like: Expansion I like the different outlook on the coding. It creates a different way of thinking
V**-1 like: Expectation You tend to think more about the expected outcome before make changes.
Z**-1 like: failure Ensuring the test fails is important - protects against poorly written or mis-targeted tests
C**-1 like: Fast Fast development cycle Immediate conformation that functions are working Test case implementation is not pushed to the end of implementation.
A**-1 like: Fast feedback Makes you think deeper about coding a module
A*-1 like: Fast feedback Think "not happy path" from the start
A*-1 like: Fast feedback When a refactor broke something, you find out immediately.
A*-1 like: Fast feedback Instant response while testing Fairly simple when explained
A*-2 like: Fast feedback Structured development process, rapid feedback on errors
A*-2 like: Fast feedback 1. use of Small steps, so not to think complex which sometime leads to move out of focus. 2. More control on code.
A*-2 like: Fast feedback Like the routine of create test, make it build, make it fail, make it pass. Repeat. It is a nice workflow.
B***-13 like: Fast feedback xxxx
B***-13 like: Fast feedback I have enjoyed the immediate feedback on code. This style does not allow you to make large changes without incrementally verifying each step.
C****-25 like: Fast feedback Nice modular work.
C****-25 like: Fast feedback Very fast feedback loop code->testing
C****-25 like: Fast feedback simple and quite straight forward
C****-25 like: Fast feedback it forces us to think about every step of code development
C****-25 like: Fast feedback Writing code incrementally; it made identifying errors easier.
C**-1 like: Fast feedback small steps you are covering you code so when adding new functionality you know very quick if you are breaking existing behavior. it is easy to go back to state where all your test are passing
E*-1 like: Fast feedback not much
H***-1 like: Fast feedback Its good to see you your code get matured with test we execute.
H***-1 like: Fast feedback -When we write the Unit Test first, we know our code will conform to some requirement -Don't have to worry about Unit Testing it later -We think about both +ve and -ve cases of a scenario in tandem
H**-1 like: Fast feedback Quick feedback, seeing quickly where I failed and how.
H**-1 like: Fast feedback I liked making changes in very small increments and getting immediate feedback on my code, then I don't get lost in what caused the error.
I**-1 like: Fast feedback How fast it was to get a test result (red/green) after doing a code change.
I**-1 like: Fast feedback test
I**-1 like: Fast feedback test
I**-1 like: Fast feedback It is fun to see tests pass and have them there easily identify which changes work and which ones don't
J***-1 like: Fast feedback I liked how quick the feedback was for "Your implementation was wrong".
J***-1 like: Fast feedback I know immediately if there are issues
J***-1 like: Fast feedback I have a safety net when refactoring my code. I feel like I can get away from the classic embedded strategy of "it works, don't touch it".
J***-1 like: Fast feedback This is me
J***-1 like: Fast feedback I know immediately if there are issues
J***-1 like: Fast feedback See errors very soon after writing the code
J***-1 like: Fast feedback I liked the feedback in the process. It's always nice getting a green bubble.
J***-1 like: Fast feedback trest like
L***-1 like: Fast feedback james test
L***-1 like: Fast feedback james test labc-1
M***-1 like: Fast feedback TDD makes the development has clear goal, we could see the result very quickly and has more confident to what we implement now. it makes us do not doubt too much on where is wrong.
M***-1 like: Fast feedback Trying to think about how we expect the function works is good. I can imagine the full framwork of the CircularBuffer. All I need is just doing the puzzle to put piece and piece of code.
M***-1 like: Fast feedback Trying to think about how we expect the function works is good. I can imagine the full framwork of the CircularBuffer. All I need is just doing the puzzle to put piece and piece of code.
M***-2 like: Fast feedback Helps find the issues with our code faster.
M***-2 like: Fast feedback Helps in identifying the bugs early on during the development stage.
N/A like: Fast feedback I like that I can add new features and test that all other things work properly.
M***-1 like: Fast feedback I liked the immediate and tactile feedback that TDD offers
M***-1 like: Fast feedback Immediate feedback, iterative development.
M***-1 like: Fast feedback Immediate feedback, iterative development.
M**-1 like: Fast feedback You find out very quickly if a new change works. You find out just as quickly if it breaks something unexpected.
M**-1 like: Fast feedback testr like
M**-2 like: Fast feedback test test
M**-2 like: Fast feedback Good practical learning experience.
N/A like: Fast feedback Hands-on experience
N/A like: Fast feedback I like how we can know what was wrong with the code instantly
N/A like: Fast feedback I like that you do things incrementally and you start off with the most simplest solution by just hard coding values and then move to more intricate solution.
N/A like: Fast feedback I liked building simple steps at a time. It makes it feel like you are making progress on problems and having the tests as a safe cushion as you make new behavior is good to have.
N***-1 like: Fast feedback hey what are you saying
N***-1 like: Fast feedback I like the building up of the design based on passing small tests for behavior.
N***-1 like: Fast feedback I like the quick feedback about my code
N***-1 like: Fast feedback Learning to code in incremental steps which helps in early bug detection
N**-2 like: Fast feedback I like the time between the tests failing and tests passing.
N**-2 like: Fast feedback makes programming simpler. you know what you have coded so far works.
R**-1 like: Fast feedback Complete new way of thinking about writing functionality
R**-1 like: Fast feedback if you invest time writing tests beforehand, it gives fast feedback if methods/code do as intended..
R**-2 like: Fast feedback Fast response and easy refactoring Quick results
R**-2 like: Fast feedback Immediately find stupid errors (e.g. off-by-one) using trivial testcases that seem to simple to write usually
R**-2 like: Fast feedback I like that you can test small code snippets following a fixed skeme
R**-2 like: Fast feedback New added functionality is tested against all finished, completetd tests
R**-3 like: Fast feedback Its a good concept to minimize bugs. You can see how your changes impact earlier tests.
R**-3 like: Fast feedback Test results are showned quickly and code regressions can be detected.
R**-3 like: Fast feedback Small groups and individual process
S***-1 like: Fast feedback I like the instant feedback and I only wrote code I needed.
S***-1 like: Fast feedback It was methodical and immediately let you know if something broke while adding new features.
S***-1 like: Fast feedback I like the inherent incremental and iterative development
N/A like: Fast feedback I like the fast and constant feedback that keeps me in check and my errors to as small as possible
N/A like: Fast feedback I liked working in small steps and receiving feedback for the small steps.
T*-1 like: Fast feedback constructed step by step development.
T*-1 like: Fast feedback more or less easy to understand how it works
T*-1 like: Fast feedback - can check source quickly - can tell us if code is uncovered
T*-1 like: Fast feedback good exercise implementation on webpage
T*-1 like: Fast feedback 'only code what you need in that moment' has fast progress while coding
T*-2 like: Fast feedback fast environment with immediate feedback
T*-2 like: Fast feedback Find quicker and earlier bugs in the code.
T*-2 like: Fast feedback If you understand the procedure, the examples are a nice exercise.
T*-2 like: Fast feedback Code is being tested while implented.
U**-1 like: Fast feedback simple approach to breaking down a problem
U**-1 like: Fast feedback I like how fast is to run the code after writing that. I mean, you don't need to compile all the flash image, flash target and test, the code runs immediately after doing it.
W**-22 like: Fast feedback I like that I can get immediate feedback on the performance and behavior of the code that I'm developing
W**-22 like: Fast feedback Creating code that progresses in complexity across multiple functions as oppose to fully building out one function at a time
W**-22 like: Fast feedback It shows you something went wrong immediately
W**-22 like: Fast feedback old mac
W**-22 like: Fast feedback new mac
W**-22 like: Fast feedback old 1
W**-22 like: Fast feedback new 1
W**-22 like: Fast feedback old 2
W**-23 like: Fast feedback hey 1
W**-23 like: Fast feedback hey 2
W**-23 like: Fast feedback hey 3
W**-23 like: Fast feedback like 1024
W**-23 like: Fast feedback I don't have to worry about if I break something. This makes me able to focus better at getting things done.
W**-23 like: Fast feedback test 1
W**-23 like: Fast feedback test 3
W**-23 like: Fast feedback test 4
W**-23 like: Fast feedback test 5
W**-23 like: Fast feedback fun
W**-24 like: Fast feedback I like having the automated tests to catch when I make a coding mistake.
W**-24 like: Fast feedback There is fast feedback when things are broken.
W**-24 like: Fast feedback New ways to think on coding with test in minde
W**-24 like: Fast feedback I don't deep into the problem before I can find it.
W**-24 like: Fast feedback I like having feedback on just what I wrote instead of waiting to have wrote my whole module and then test it and start debugging the whole module at once because certainly there are errors inside.
W**-25 like: Fast feedback Testing interleaved with development. Instant feedback.
W**-25 like: Fast feedback When I do break testable behavior, I find out immediately, when I still remember the changes I was making.
W**-25 like: Fast feedback I said this already, but the framework is pretty easy to work with.
W**-26 like: Fast feedback I liked that I was forced to test one thing at a time
W**-27 like: Fast feedback Find errors with the code almost instantly.
W**-28 like: Fast feedback I liked seeing instant results to my failing tests after making them pass.
W**-28 like: Fast feedback The confidence that when something is done it is truly DONE.
W**-28 like: Fast feedback Start making progress right away - no analysis paralysis.
W**-28 like: Fast feedback Short, fast iterations.
W**-29 like: Fast feedback Fast feedback
W**-29 like: Fast feedback Getting a pass/fail straightaway is refreshing.
W**-29 like: Fast feedback I liked getting instant feedback about small changes
W**-30 like: Fast feedback web-30
W**-31 like: Fast feedback Fast feedback
W**-31 like: Fast feedback Getting immediate feedback when I make an error
W**-31 like: Fast feedback Like the small steps.
W**-32 like: Fast feedback There was instant feedback on how my code was working
W**-32 like: Fast feedback Error analysis and possible maintenance work are easier and faster
W**-32 like: Fast feedback I can start writing code and get feedback right away. Sometimes the hardest part of any project is getting started or restarting once you've stopped.
W**-33 like: Fast feedback I like the granularity; it helped me stay productive without overthinking (or thinking too far ahead of where I was at).
W**-33 like: Fast feedback I like how I haven't written a lot of C/C++ code in years, and working in small steps makes it attainable for me.
W**-34 like: Fast feedback Liked getting instant feedback while solving a puzzle to one interesting piece of the code and its test. I also really liked to feedback about over developing code.
W**-35 like: Fast feedback I liked that I got incremental feedback without having made too many changes at once and having to backtrack.
W**-35 like: Fast feedback Fast feedback loop: Error is usually only a few clicks away.
W**-35 like: Fast feedback systematic safer way forward
W**-35 like: Fast feedback Quick feedback if the code works
W**-35 like: Fast feedback immediate response to small code change
W**-35 like: Fast feedback A new approach to get solid code.
W**-35 like: Fast feedback Making the test prior to the implementation gives a good feeling in terms of "My code is already passing the tests".
W**-36 like: Fast feedback You get to see that you have introduced a bug or broken something almost immediately.
W**-37 like: Fast feedback Loved small increments.
W**-37 like: Fast feedback I like that I got feedback on issues I would not have typically seen so early in the development process.
W**-38 like: Fast feedback Pair programming was really nice, my partner and I switched after every yellow, red, green cycle which was a great cadence. We completed the entire exercise with time to spare!
W**-38 like: Fast feedback Small incremental steps that drive design.
W**-38 like: Fast feedback james test
W**-39 like: Fast feedback The pace is adapted to the people taking the course and the guidance is excellent.
W**-39 like: Fast feedback The exercise is interesting
W**-39 like: Fast feedback The exercise is interesting
W**-40 like: Fast feedback We have found multiple issues with the code as we progressed. Without TDD this would not have been possible.
W**-40 like: Fast feedback tests ware already sketched
W**-40 like: Fast feedback Progress is fast, especially when pair programming
W**-41 like: Fast feedback Ability to test each step of the way. If we design the test flow right, I can see how we can build a strong foundation
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.
B***-12 like: feedback I like the fast feedback loop. You're compiling and running very quickly after you start.
B***-12 like: Feedback Quickly able to verify changes didn't break previously working features.
B***-12 like: feedback quick feedback when a change broke something
L*-4 like: Feedback responsive , feedback
T**-1 like: feedback Quick feedback for both my successes and failures.
V**-1 like: Feedback Fast feedback. It's rewarding to get lots of successes
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**-21 like: feedback I like building up quick wins. I know I'm making progress.
Z**-1 like: Feedback Fast feedback from tests about what does and doesn't work in the implementation.
Z**-1 like: feedback I like that it provides quick feedback as I'm writing code.
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.
V**-1 like: Feels confident Gives enough satisfaction about the code written.
V**-1 like: FewerBugs It is easy to trace
A**-1 like: Find problems quickly New possible errors not known befire testes.
A**-1 like: Find problems quickly I feels that it is much more complicate to enter a bug.
A**-1 like: Find problems quickly I like that you feel that what you are coding is more robust and bugless
A**-1 like: Find problems quickly I like that you can find more quickly the problems when you don´t know the good request from your code
A**-1 like: Find problems quickly This methodology forces you to firstly think on how to make it fail, and avoid "working" assumptions. Also the way of making the test pass quickly makes the code to keep simple.
A**-1 like: Find problems quickly I like to have a process to follow which should help to avoid making mistakes.
A*-1 like: Find problems quickly I liked that you see when changes makes old tests fail.
A*-2 like: Find problems quickly "automatic" bugfixing
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
C****-25 like: Find problems quickly Incrementally driving code with tests helps to find issues quickly.
C****-25 like: Find problems quickly Idea of writing test before production code is really effective in pointing to code that can cause the failure. Makes the code coverage 100% automatically. helps in keeping design logic simple
C**-1 like: Find problems quickly Didn't have to setup or go through that. Nice UI and easy to start understanding TDD with hands on experience
E*-1 like: Find problems quickly Test as you build
E*-1 like: Find problems quickly Forces a different way of coding to look for a problem before adding/fixing it.
H***-1 like: Find problems quickly I like that when refactoring the code, previous tests fail when something not updated correctly.
H***-1 like: Find problems quickly Already existing tests helps to avoid mistakes during development
H***-1 like: Find problems quickly It does seem to lead to a small steps with with success approach.
H**-1 like: Find problems quickly The ability to create more methods with the confidence my previous methods worked.
H**-1 like: Find problems quickly Test each feature as you build it, rather than building a list of things to test later. Should be good about enforcing explicit testing of edge cases, buffer overflows, etc.
I**-1 like: Find problems quickly Simple, step-by-step procedure to write bug-free code.
I**-1 like: Find problems quickly I liked making the tests work as we built new functionality.
M***-1 like: Find problems quickly I can find problem and debug quickly.
M***-1 like: Find problems quickly I can find problem and debug quickly.
M***-1 like: Find problems quickly I can find problem and debug quickly.
M***-1 like: Find problems quickly step by step testing and found out the problem, in the end create the fully test.
M***-1 like: Find problems quickly Of cause, Yes. It is the way to step by step to find the request, and find the answer and try it. Then fix the coming unexpected bugs. Then keep going to access the final goal.
M***-1 like: Find problems quickly It's interesting class, we can write the code and debug together.
M***-1 like: Find problems quickly It makes the debugging easier and I can find the defects earlier.
M***-2 like: Find problems quickly test test test
M***-2 like: Find problems quickly I like the benefit of finding and resolving bugs faster with TDD approach.
M***-2 like: Find problems quickly Helps find code shortfalls quickly.
M***-2 like: Find problems quickly Keeping things simple in unit tests saves a lot of time giving the same quality of test case. DTSTTCPW
M***-1 like: Find problems quickly it may minimize coding mistakes/bugs earlier on
M***-1 like: Find problems quickly it may minimize coding mistakes/bugs earlier on
M***-1 like: Find problems quickly TDD can detect potential bugs and test functionalities of methods in advance.
M***-1 like: Find problems quickly TDD can detect potential bugs and test functionalities of methods in advance.
M***-1 like: Find problems quickly I liked how it got you thinking about the requirements in the coding process. The code being built is handling all the aspects of the design I've thought about because of this incremental approach.
M**-1 like: Find problems quickly How progressive it makes the coding process and that when you jump the gun, you see what breaks.
M**-1 like: Find problems quickly By working in small increments, you know that any errors are confined to the change made since the last test pass.
M**-1 like: Find problems quickly Once we got the rhythm, we got instant feedback and can look back at the progress we made in a short time.
M**-1 like: Find problems quickly Immediate failure feedback on previous tests
M**-1 like: Find problems quickly Small steps for easy debugging
M**-2 like: Find problems quickly I liked the team programming environment which allowed on the fly code improvements from those watching while watching the person who was typing out the code.
N/A like: Find problems quickly Focused attention on implementation explicitly as a step by step approach.
N/A like: Find problems quickly The tight loops helped debug the code quicker.
N***-1 like: Find problems quickly this is a test
N***-1 like: Find problems quickly Catching errors quickly
N***-1 like: Find problems quickly Small changes let you find the problems quickly.
N**-2 like: Find problems quickly I like that there is an iteration process of a failed test followed by a pass test and once you are finished you have all of your tests setup.
R**-1 like: Find problems quickly Easy to track down the issues
R**-1 like: Find problems quickly Since we work step by step, we find the problem more quickly
R**-2 like: Find problems quickly If our testsuite is running a memory checker like ASAN, we can find memory issues (use-after-free, leaks) in our codepaths.
R**-3 like: Find problems quickly it makes testing easier and debugging faster
R**-3 like: Find problems quickly Structured development process
R**-3 like: Find problems quickly jsdl;kfjsdlkfjs sfjksfklsfksj fsdfsd
S***-1 like: Find problems quickly rapidly detecting errors, mostly the ones i caused. framing tests drives production software, only builds capability needed for test. iterative development
N/A like: Find problems quickly Love the incremental devlopment
N/A like: Find problems quickly Love the incremental devlopment
T*-1 like: Find problems quickly Programming errors are detected at an early stage.
T*-1 like: Find problems quickly fast feedback
T*-1 like: Find problems quickly Its easy to use.
T*-1 like: Find problems quickly You see immediately when something breaks existing functionality
T*-2 like: Find problems quickly Its power to prevent mistakes turning into bugs, sparing developer and testing team quite some time.
U**-1 like: Find problems quickly Liked the approach as it allows to start testing at early stage.
U**-1 like: Find problems quickly I like find bug when I change code
U**-1 like: Find problems quickly I like find bug when I change code
U**-1 like: Find problems quickly I like find bug when I change code
W**-23 like: Find problems quickly Small changes results in less time in the debugger - I can easily deduct what the problem is.
W**-23 like: Find problems quickly TDD is good at catching errors very early.
W**-23 like: Find problems quickly nice to work against something very specific, where the requierements are very clear. no guessing
W**-23 like: Find problems quickly test 2
W**-24 like: Find problems quickly verifiable progress
W**-24 like: Find problems quickly Refactoring was easier to debug because of the previously built up tests.
W**-24 like: Find problems quickly It forced me to think about the problems at hand before I start coding thinking I know know the problem's soluion.
W**-25 like: Find problems quickly It's nice to have some confidence in code correctness as it's written. The framework seems easy enough to work with.
W**-25 like: Find problems quickly Mandates writing cleaner code in small units, with lesser chances of breaking something with new code.
W**-26 like: Find problems quickly If you change something and it breaks a previous test, you know immediately.
W**-26 like: Find problems quickly Made me slow down and think about the test and ways the code could fail before writing code.
W**-27 like: Find problems quickly The feeling that you are always progressing
W**-27 like: Find problems quickly Code design along with the test cases to find potential errors at the beginning
W**-28 like: Find problems quickly I do like that it encourages the breaking down of complex problems into simpler steps. I can defiantly see how this extra time up front could help in the long run.
W**-29 like: Find problems quickly It's clear where the error was
W**-29 like: Find problems quickly I don't have any C++ experience, but I liked that similarly to C#, compiler languages force you to deal with bugs immediately instead of saving surprises for you later.
W**-30 like: Find problems quickly I like that it increases my ability to Focus on one thing.
W**-30 like: Find problems quickly I liked that I got immediate feedback for what was going on with each test. If a test failed, I know exactly what the test is testing and can trace what went wrong.
W**-30 like: Find problems quickly I appreciate the fact that I'm forced to evaluate not just what a function should do, but also what it shouldn't.
W**-31 like: Find problems quickly When I broke the implementation, whilst adding a feature, the failing tests were really useful
W**-31 like: Find problems quickly Small steps gives you constant feedback. It is easier to see where the problem is introduced.
W**-33 like: Find problems quickly small changes makes it easier to find the problems (in theory)
W**-34 like: Find problems quickly I like the idea of a feedback loop. Continuously getting feedback from the code as it's developed.
W**-34 like: Find problems quickly It will help catch bugs early in the process. It also makes you think more before coding
W**-34 like: Find problems quickly Easy to identify when new code breaks existing work.
W**-34 like: Find problems quickly It letd me test the function that is just implemented, which helps to quickly find out issues if any.
W**-35 like: Find problems quickly Seems good at catching errors.
W**-35 like: Find problems quickly Errors you run into seem to be small local problems instead of the occasional larger issues you can get with traditional development.
W**-35 like: Find problems quickly Very fast feedback if my implementation works. The solution can be quickly found.
W**-37 like: Find problems quickly After adding changes it is easy to see where code stops working. Need to mention, that informative test names are must!
W**-38 like: Find problems quickly I like the fact that you can begin writing code without completely understanding how everything should function.
W**-38 like: Find problems quickly I like that I didn't need to understand how the entire program should be implemented. I just needed to understand how to pass the test.
W**-40 like: Find problems quickly I liked that later on in the TDD process, older tests would fail during a refactor, immediately showing us bugs we created.
W**-40 like: Find problems quickly Think before writing production code Catch unexpected edge cases
W**-40 like: Find problems quickly I could find a sneaky bug from a previous implementation
W**-41 like: Find problems quickly You can find bugs in code right away
W**-41 like: Find problems quickly - Thinking about the use cases before designing the code - Breaking the functionality into small pieces eases the work.
Z**-1 like: Find problems quickly found bugs fast
Z**-1 like: Find problems quickly Getting stuff working
B***-2 like: Finding defect early Finding defect early.
D****-2 like: FixFast I like the short time between failure through diagnosis to fix.
T**-1 like: flow Good work flow (write tests first, build on-top of tests).
D****-2 like: focus Helps frame the design by forcing to focus on one detail at a time.
T**-1 like: forced perspective I enjoyed the minimal development approach. It forced me to adopt another perspective for debugging
C*****-2 like: Found difficult bugs The tests and the tool did discover things like memory-leaks and writing out of bounds, these are difficult to find problems.
C*****-2 like: fulfilling Seeing progressive improvement was great. Able to execute my code without it being part of a larger component
A*-2 like: Fun Less complicated than expected
B***-13 like: Fun Allows for multiple refactoring without limits
C****-25 like: Fun Its very fun
C****-25 like: Fun We get to write code, that's small fun and easy
J***-1 like: Fun It feels silly to build the interface to just return 10 to force a passing test, knowing it'll break later but it's "good enough" right now. https://dilbert.com/strip/2001-10-25
L*-4 like: FUN I felt testing and debugging was fun. Before taking this class, I really didn't like debug my code.
M***-1 like: Fun Practice to think by TDD when doing exercise.
M***-1 like: Fun It is good experience to improve the code debug cycle time
M***-2 like: Fun Very good experience. Was able to collaborate with part and trainer easily.
M***-2 like: Fun Very nice collaborative experience.
M**-1 like: Fun give an idea of how project can be broken out into modules and developing it in parallel.
N/A like: Fun I like the fact that it enables you to have explicitly defined requirements and informs you when your implementation deviates from those. I also like the sharing of ideas between developers.
N/A like: Fun I like the fact that it enables you to have explicitly defined requirements and informs you when your implementation deviates from those. I also like the sharing of ideas between developers.
N**-2 like: Fun It is almost like learning a new programming language from scratch. So, you start from the basic, and you work your way up.
R*-1 like: Fun fun
R*-1 like: Fun fun
R**-1 like: Fun The exercise environment (cyber dojo) is really cool.
R**-2 like: Fun I like to get the green light. It feels like I reached a checkpoint where I can go back to if I mess up later.
U**-1 like: Fun It is more interactive.
W**-22 like: Fun after updating email
W**-27 like: Fun When using TTD it gives you natural progression and structure in solving the problem.
W**-29 like: Fun It slows down the process and makes you think about all the edge cases that might occur. Helps break down the process into smaller steps.
W**-30 like: Fun Time is flying
W**-30 like: Fun it is a very unique way of coding and thinking and i like it but it is a bit challenging one too
W**-30 like: Fun I liked the Code Dojo concept - that made the setup and course stress FREE.
W**-32 like: Fun It's more fun and less stressful.
W**-33 like: Fun I really like the sense of progress and accomplishment that TDD brings me. I like the usage of the #defines to turn on one test at a time, never tried that before in cyber-dojo.
W**-33 like: Fun James' light-hearted humour is a joy to follow ! Good thing you don't charge extra for liking more than one thing...
W**-35 like: Fun It was fun to achieve small goals quickly!
W**-40 like: Fun I like the idea of procrastinating - I think I can be very good at this
W**-41 like: Fun the website
M***-1 like: Function it seems to force you to really think about the function and responsibilities of parts of the code
B***-12 like: future-proof It can prevent working portions of the code from breaking
B***-12 like: Gamification It is satisfying to "solve" tests.
B**-1 like: good a good test suite
T**-1 like: good good overview enjoyed the practical so far
T**-1 like: GOOD It is a good learning experience so far. It gives a good structural/procedural (test) approach to developing code while solving problems.
W**-21 like: Good Approach I like the approach of the TDD training session
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
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
W**-21 like: Great, confidence, I feel its great way to developing code, one can be confident it will work. Small pieces to perfection like production. Build/running code always present even it may not fully functional.
W**-21 like: guidance TDD guides you to a clean interface and minimal implementation.
B***-1 like: harness I liked the harness driven approach. It is faster than debugging.
V****-2 like: Helps Helps you catch bugs early on
A**-1 like: High test coverage It forces you to write testable code
C****-25 like: High test coverage Sure not to develop unused code
C****-25 like: High test coverage Trying out a different development style than what I am used to.
H***-1 like: High test coverage I like that the tests are already written when the code is done.
H***-1 like: High test coverage Good approach to have incremental regression tests for each and every small part of my software.
H**-1 like: High test coverage I like the idea of having more complete testing coverage at the very beginning of implementation.
H**-1 like: High test coverage I like the idea of having more complete testing coverage at the very beginning of implementation.
I**-1 like: High test coverage I liked the idea that there's a test for each feature
I**-1 like: High test coverage The idea of writing only code that is testing, i.e. we would get 100% test coverage.
J***-1 like: High test coverage When running a newer test, I have confidence that I did not break an early design element
J***-1 like: High test coverage Forces you to think through and test the expected behavior at each step.
M***-1 like: High test coverage It keeps the test simple. Sometimes writing code can get you too deep into the thought and lost the meaning of testing code. I think TDD is an efficient way for testing my work.
M***-2 like: High test coverage It was a interesting problem and learn new test cases for circular buffer. The trainer is good and ready to help.
M***-2 like: High test coverage Minimal setup needed. So, more focus on writing test cases
M**-1 like: High test coverage seeing the code getting build, just by passing the tests
M**-2 like: High test coverage I am starting to see the way that this could help build good test coverage on new code.
N/A like: High test coverage Good test coverage
N/A like: High test coverage I like that there is always a test for each piece of production code.
N/A like: High test coverage Thoroughly written tests eliminate bugs. Requirements can be translated into tests - a test for each requirement or sub-requirement if they can be broken down.
N***-1 like: High test coverage I like being told what parts of my code are not covered by tests
N**-2 like: High test coverage Re enforcing don't write code you don't need. I liked how in your instructions you stated 'you do not need dynamic allocation yet' and 'gets were static'.
R**-1 like: High test coverage See the deviance directly
R**-1 like: High test coverage Someone who wants to modify my code will have to respect all my tests (given he doesn't just strip the tests down, but that's another topic).
R**-1 like: High test coverage It turns my world upside down.
R**-2 like: High test coverage something from james
S***-1 like: High test coverage I like that all the code I write is being tested and that the tests don't need continual manual updates.
S***-1 like: High test coverage You are building your tests as you develop rather than doing it after the fact.
T*-1 like: High test coverage Good exercise on function/test splitting
T*-1 like: High test coverage fast feedback
U**-1 like: High test coverage It forces you to test every line of code.
U**-1 like: High test coverage It is some fun. It gives the impression that you have full control over the code you are writing. Separation between tests and production code is natural
W**-22 like: High test coverage Completion and actuation of high level features before low level realization. Usable regression record that builds during development
W**-22 like: High test coverage I like the idea of consistently testing code during development.
W**-22 like: High test coverage I like the idea of consistently testing code during development.
W**-22 like: High test coverage I like the idea of consistently testing code during development.
W**-22 like: High test coverage I like the idea of consistently testing code during development.
W**-22 like: High test coverage It's organized and thorough
W**-28 like: High test coverage I always liked it because it helped me break down problems and force myself to make unit tests up front when I might not go back and do later if not.
W**-30 like: High test coverage First thing this is completely new to me. So I liked the thing that I am learning something new. Secondly for each line of code we can write a test case and test it.
W**-30 like: High test coverage Thoroughly testing individual functionality.
W**-33 like: High test coverage It seems it allows us to test our applications as thoroughly as we developers need it to
W**-34 like: High test coverage It make you think of all the different test cases.
W**-35 like: High test coverage Writing test is a simpler way to start the coding actual logic and see it pass. Less chances of finding bugs later in the app. working as a team where you can share and listen other person's thoughts.
W**-36 like: High test coverage I like that it helps in covering all paths
W**-38 like: High test coverage The ability to already have test written before beginning the code; also, having a large test base will help discover new bugs introduced by later code changes.
W**-38 like: High test coverage The ability to already have test written before beginning the code; also, having a large test base will help discover new bugs introduced by later code changes.
W**-38 like: High test coverage The ability to already have test written before beginning the code; also, having a large test base will help discover new bugs introduced by later code changes.
W**-38 like: High test coverage The ability to already have test written before beginning the code; also, having a large test base will help discover new bugs introduced by later code changes.
W**-40 like: High test coverage Increased test coverage.
W**-40 like: High test coverage - Direct Feedback on the actual implementation - lets me think about the exceptions while there is no need of having the full complexity of the module implementation in mind
W**-40 like: High test coverage - Direct Feedback on the actual implementation - lets me think about the exceptions while there is no need of having the full complexity of the module implementation in mind
W**-40 like: High test coverage - Direct Feedback on the actual implementation - lets me think about the exceptions while there is no need of having the full complexity of the module implementation in mind
W**-40 like: High test coverage - Direct Feedback on the actual implementation - lets me think about the exceptions while there is no need of having the full complexity of the module implementation in mind
W**-41 like: High test coverage Existing tests catch when new code breaks old functionality
W**-41 like: High test coverage Good test coverage on the implementation.
Z**-1 like: High test coverage kjhakj akjalkjakjakj dkfjsdfjksd
Z**-1 like: Immediacy The short time between writing something wrong (even in so trivial an example as a circular buffer) and finding the mistake.
L*-4 like: immediatly check error case & handle it immediately.
L*-4 like: in progressive I liked that I can make the code in progressive from zero to hero.
B***-11 like: Incremental Incremental development so always testing and find bugs early
C**-1 like: incremental It's methodical, with only small changes made with each cycle
C**-1 like: incremental It breaks down the problem. Enforces incremental development. Ensure that new features do not break existing ones.
D****-2 like: incremental small incremental progress in the right direction == good
V****-2 like: incremental Made inclemently implementing features easier.
W**-18 like: incremental Incremental progress.
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.
C**-1 like: increments Small increments are easier to manage
B***-12 like: instant Instant feedback if code is working
W**-19 like: Instant Feedback Instant feedback if code is broken.
F**-1 like: Interesting TDD can help us develop/test software while developing. It can slow at start but wonderful when complete.
V****-2 like: Interesting TDD is a good a approach to systematically solve a programming problem, as the bugs can be fixed on the go.
V****-2 like: interesting It gave me an idea of how to write fewer bugs in my code.
W**-18 like: interesting Its an interesting way to test software. Which is a new experience for me.
Z**-1 like: interesting it's an interesting and different approach for solving a problem.
B***-2 like: Interfaces Forces you to specify out your interfaces early (pre- actually implementing them)
W**-18 like: intriguing Gave me a new perspective on Software development.
V**-1 like: iterativ fast feedback with small changes
C*****-2 like: iterative The iterative nature of TDD. For the most part, it allowed you to focus on smaller pieces of the code.
C*****-2 like: iterative Helps to ingrain iterative development into oneself.
V**-1 like: iterative The iterative approach to tested when done
V**-1 like: K.I.S.S I liked the fact that you "eliminate" adding code that is not necessary and thus keep complexity to a minimum
T**-1 like: language Not a new language to learn, more or less
W**-18 like: Learning Learning about CPPU Test and a different development methodology and how I can apply it to my development style.
W**-20 like: lego Short iteration with short implementation. You get more understanding of the code that you write.
B***-1 like: like Minimizing the number of changes between executions of the test which reduces the possible causes of the failures.
V****-2 like: like incremental development. validate, test, necessity of a , need for variables in microscopic details. emphasis on code coverage
C*****-2 like: loop I liked that the environment allowed for quickly running tests and seeing results.
B***-11 like: love Not really first impression, but TDD is a game-changer that makes code development easier, safer and more predictable.
L*-4 like: makeing test code I like making test code. it's a effective experience.
W**-19 like: Memory Reminds you where you are on a task if you get distracted
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***-12 like: methodical I like that the development process is very thorough, methodical, and structured.
W**-19 like: methodical Very methodical. I liked slowly working through all the implementation details through specific tests.
W**-20 like: methodical The ability to test along the way ... takes care of the unit testing
W**-21 like: mindset change Fail early, fix quickly
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.
A**-1 like: Minimal implementation this is an good tool to verify the written code.
B***-13 like: Minimal implementation It was interesting, not having to figure out the entire data structure and interface first. Iterative.
C****-25 like: Minimal implementation forces you to get to the minimum complexity to meet requirements (expressed by tests)
C**-1 like: Minimal implementation Less load on the brain by tackling one small step at a time. Less mistake working with small steps
H***-1 like: Minimal implementation Its interesting. Even though it was straight forward what data structure we have to use, we still managed to pass some test cases without it. Ultimately tests forced us to adapt to the structure.
I**-1 like: Minimal implementation I liked the fact that you write only the code you need
J***-1 like: Minimal implementation Helps with coding only what is needed and not more than that.
J***-1 like: Minimal implementation I liked the incremental build and test style. It keeps you focused on not tackling too much of the problem at once, which limits how complicated the tests are.
M***-1 like: Minimal implementation This first exercise in TDD helped me think differently, and I often caught myself starting to write code ahead of the tests.
M**-1 like: Minimal implementation Code is only written if it is required for a test. This means that every line that exists is vital; none of the code is redunant. The code coverage feature of the dojo really helped with this.
N/A like: Minimal implementation Helps you break things down to the most basic functions.
N/A like: Minimal implementation Kept things simple
R**-1 like: Minimal implementation Dealing with a very focused code, and minimal change
S***-1 like: Minimal implementation I liked moving forward in small chunks. Each step was very simple.
N/A like: Minimal implementation So far, TDD makes me overthink less
N/A like: Minimal implementation I like the iterative and incremental nature of TDD.
T*-1 like: Minimal implementation You only implement enough to pass the tests.
T*-1 like: Minimal implementation fast approach to goal
T*-1 like: Minimal implementation fast approach to goal
T*-2 like: Minimal implementation simple, small test functions, testing only part of my code
U**-1 like: Minimal implementation Not need to focus on the entire problem at once.
W**-22 like: Minimal implementation Is this unit test macros available to use. easy to modify for our output needs?
W**-22 like: Minimal implementation making small changes at a time
W**-23 like: Minimal implementation It keeps the focus on exactly the feature that's being implemented
W**-24 like: Minimal implementation Taking small steps
W**-24 like: Minimal implementation TDD forces you to only implement what's required. Also what's implemented has tests.
W**-29 like: Minimal implementation I like the approach of incremental development, bakes it easy to break up large tasks into simple problems.
W**-30 like: Minimal implementation I like the process of TDD. It's like Scrum - when you do it properly it works. First of all see that failing test.
W**-30 like: Minimal implementation Keeping it simple.
W**-31 like: Minimal implementation No need to lose your thoughts in complex functions.
W**-31 like: Minimal implementation No need to lose your thoughts in complex functions.
W**-31 like: Minimal implementation No need to lose your thoughts in complex functions.
W**-32 like: Minimal implementation Unnecessary code in production code is avoided
W**-34 like: Minimal implementation TDD allowed me to overcome a great problem: creativity blocks.
W**-35 like: Minimal implementation slice the problem into small steps => reduce the complexity
W**-35 like: Minimal implementation Simple. Short easy goals for each function, adding scope over time.
W**-35 like: Minimal implementation I like that the tests are fairly straightforward once you get the concept
W**-35 like: Minimal implementation typically it's less work than expected per test
W**-37 like: Minimal implementation I like that it allowed me to focus on one thing at a time. Working on one simple thing at a time and testing made it easy to not get too large or complex before testing.
W**-38 like: Minimal implementation We moved in small steps and incrementally worked out an API. Nice use of ZOM...
W**-38 like: Minimal implementation Breaking down a larger task into smaller more manageable tests.
W**-38 like: Minimal implementation Breaking up a big issue into smaller segments
W**-38 like: Minimal implementation Breaking up a big issue into smaller segments
W**-38 like: Minimal implementation Breaking the problem down into small (initially insufficient) incremental steps.
B***-11 like: minimalist I like the idea of not building anything more than what you are currently testing.
C**-1 like: mistakes Experiencing mistakes I do in coding, like wrong checking
B**-1 like: modular The coding and logic manipulations. Forces modular 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: New Learning a new development approah, writing a test before writing the implementation.
W**-25 like: None not sure if I like it.
C*****-2 like: not as much overhead The process did get easier as the implementation became more complete.
C*****-2 like: nothing nothing.
A*-1 like: Other. Think "not happy path" from the start
A*-1 like: Other. Think "not happy path" from the start
E*-1 like: Other. I like that I can run tests over and over fairly easily.
E*-1 like: Other. breaking the problem down into very small testable increments
J***-1 like: Other. You develop a test suite for your code as you write the code. This has immense value.
L****-1 like: Other. Focusing on the smallest possible implementation that worked helped me write better tests. Almost like trying to trick the test (hardcoded values, etc.). This meant I needed better tests to actu
N***-1 like: Other. Helps to find small bugs like typos right off the bat.
N***-1 like: Other. A good approach to testing, the instructor is helpful. TDD can help break the problem into smaller chunks may help converge to the solution faster.
R**-1 like: Other. I had a feeling that I already knew quite well what TDD was about, but I had a wow effect about points I didn't see before.
R**-1 like: Other. I like how the incremental approach makes my code change and evolve allowing me to go from stupid to more complex as the test become more demanding.
W**-29 like: Other. Seems to force breaking the task into bite-sized pieces.
W**-38 like: Other. I liked how detailed the guidance was on the first exercise
W**-40 like: Other. TDD is good at capturing requirements: you have a requirement, you write a test for it, then you implement the requirement
Z**-1 like: Other. this and that
D****-2 like: Oversight TDD help prevent creating undetected bugs in existing code when making modifications or refactoring.
L*-4 like: passes I liked making code to pass the test, even though the test was simple.
C**-1 like: peace of mind Having confidence that my code is somewhat tested
T**-1 like: Piecemeal Forces you to think in little (testable) pieces
C**-1 like: positive feels like you can make significant progress without completing much functionality
Z**-1 like: Precision The idea of finding a way to codify your class' behaviour before you write it
W**-21 like: presence TDD saves you from thinking about future problems too early.
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.
Z**-1 like: prioritize I like that it pushes writing tests to the forefront of your mind when programming, not just an afterthought.
Z**-1 like: Proactive Focus on testing upfront.
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.
W**-21 like: Process It's a process
C**-1 like: procrastination it is OK to be a 'lazy' programmer, and procrastinate until you are forced to.
V**-1 like: Progress The instant feedback of progress.
C**-1 like: progressive I liked that it was testing chronological building blocks. Building into larger more complete pieces of code.
B***-11 like: Promising Better opportunity to validate expected behavior and move on, while also identifying and testing edge cases.
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
L*-4 like: proof I can get each line of code tested.
V**-1 like: Quality Quick feedback loop when implementing -> continuous improvement.
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.
B***-12 like: quick Quick feedback
B***-12 like: quick Quick feedback
B***-1 like: Quick results Quick feedback when there is a but in the code.
B***-11 like: Refactoring Easy refactoring. I know that things haven't been broken by a change.
C**-1 like: refactoring Helps with refactoring.
W**-21 like: regression Like that it creates way to check other changes that shouldn't change functionality and provides regression
W**-20 like: regularity I like the regularity of the steps: do the same process, one bit at a time
W**-20 like: reliable I like that you test as you go and so your code is more reliable.
M***-1 like: requirements I like that you can map requirements to code more easily.
V**-1 like: Rewarding It is rewarding to see the result immediately (not so rewarding when breaking a test ;-) )
B***-12 like: robust You can refactor/add code with less worry about breaking existing functionality
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.
L*-4 like: Safe While developing code with TDD by step by step, my code became better and I don't have to worry about the function that wrote before.
L*-4 like: safe code I got the feeling of building up the code.
B***-2 like: safer Feels safer to change code
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.
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.
V**-1 like: safety net easy to change without risk of breaking something
W**-20 like: safety-net I like how the tests seem to "lock in" the behavior as you go along
L*-4 like: Satisfaction TDD makes me feel some satisfaction and progress.
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: Sensible The concept of driving development by testing makes a lot of sense. I'll definitely be using this approach in the future.
L*-4 like: separated Complex implementations can be simply separated.
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
D****-2 like: short failures That there are only short intervals of being in a state of not-working.
C*****-2 like: show I like having the tests to show me what's not working.
B***-2 like: simple Clear, simple framework
C*****-2 like: simple it dosent take a lot of effort to make your code pass
D****-2 like: simple I liked the incremental approach.
T**-1 like: simple Can concentrate on very small functionality at a time.
B***-2 like: simplicity I like the iterative develop to get the smallest solution working.
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.
M***-1 like: Simplicity 1 Thing at a time
M***-1 like: Simplicity forced to focus on one thing at a time
M***-1 like: small I like that it forces you to implement the code step by step, with small increments.
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.
M***-1 like: small step software problem are divided is many smaller problem that are more easier to fix.
M***-1 like: small steps its breaking up development into small steps
W**-21 like: small steps Like that it forces small steps
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.
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.
L*-4 like: Stable If test code gets well made, it looks we can make really stable S/W at the first time.
L*-4 like: step by step I can develop step by step more logically.
C**-1 like: straightforward It is a more straightforward/mechanic method to develop
F**-1 like: Strong Very simple. Easy for understand
V**-1 like: Structure Enforces you to not add unnecessary code -> adds structure to the process of implementation.
B***-1 like: structured It's structured, that helps to detect errors earlier.
M***-1 like: structured It forces you to create the API functions early in the process
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.
A**-1 like: Structured approach Things should be done step by step.
A**-1 like: Structured approach Thinking about the corner-cases before doing the implementation helps you reach a better implementation
A**-1 like: Structured approach It's a sistematic way of performing tests and it helps you to think first on the module API before program it. Also helps you to avoid future errors because tests must continue working.
A**-1 like: Structured approach I like the simplicity, the structured way of implementing the code.
A*-1 like: Structured approach Good presentation Nice to have exercises and quick feedback Structured way of coding
A*-1 like: Structured approach I liked the systematic approach to ensure a safe code
A*-1 like: Structured approach It was interesting
A*-2 like: Structured approach Easy to run tests with Cpputest framework
A*-2 like: Structured approach Kinda forces a more structured way of coding.
A*-2 like: Structured approach How I need to wait and realise what I need to test without adding extra functionality.
A*-2 like: Structured approach I like the test of the test approach
B***-13 like: Structured approach Forces you to think about all the edge conditions.
B***-13 like: Structured approach Offers a structured method to developing software.
B***-13 like: Structured approach Let you build tests that you were confident in even if the implementation underneath was only half-cooked
C****-25 like: Structured approach Code driven by interface
C****-25 like: Structured approach it makes clearer the requirements.
C****-25 like: Structured approach I like how it brings into the dev process a formal and compiled definition of requirements. This is quite nice, because allows you to develop a minimal amount of code that fulfill the requirements.
C****-25 like: Structured approach It makes easier defining better signature (good for sharing)
C****-25 like: Structured approach The constant reminding of precise definition of what the functionality is supposed to do.
C****-25 like: Structured approach I need to think about few things at one given moment
C****-25 like: Structured approach Clear method
C****-25 like: Structured approach TDD makes development & unit testing well structured. It makes easy to see what's tested and what's not.
C**-1 like: Structured approach It's easier to break down the problem into smaller pieces if there is already a test describing what the code should do.
C**-1 like: Structured approach Iterative and incremental with tests baked in feels good. Don't need to race too ahead of time.
E*-1 like: Structured approach iterative testing
E*-1 like: Structured approach I liked pair programming, breaking the problem up into manageable parts
E*-1 like: Structured approach I like the baby step approach to developing code.
E*-1 like: Structured approach It requires you to state and describe the behavior you want.
E*-1 like: Structured approach It forces you to analyze and implement concise member functions while testing/validating the input to those function.
E*-1 like: Structured approach the TDD method is very interesting and the step to add code step by step according test case
H***-1 like: Structured approach I liked how this enables us to build step by step to arrive at a final solution.
H**-1 like: Structured approach Since I'm new to C++ (former C user), it was nice to both dabble in C++ and learn TDD at the same time.
H**-1 like: Structured approach It Breaks down a task into small manageable chunks that make it easier to complete a difficult task. It Breaks down a task into small manageable chunks that make it easier to complete a difficult task
H**-1 like: Structured approach I like the way the course steps you though each new Test.
H**-1 like: Structured approach I like the way the course steps you though each new Test.
I**-1 like: Structured approach I like the exercise - simple and easy to understand the principles.
I**-1 like: Structured approach i like how my code was getting incrementally more and more complete
I**-1 like: Structured approach It allows me to write the code organically through tests.
I**-1 like: Structured approach The build & run environment being all set up. It's a nightmare getting many students set up individually.
I**-1 like: Structured approach Methodical
I**-1 like: Structured approach TDD makes you step away from the nitty gritty details and instead focus on the intended functionality of your API.
I**-1 like: Structured approach Frameworks are good
J***-1 like: Structured approach I like how sequential it is and how it leads you through a prescribed process.
J***-1 like: Structured approach I appreciate the self-directed flow using comments as a "discussion" and the #def as a stop point.
J***-1 like: Structured approach Starting point is relatively simple
J***-1 like: Structured approach I liked that the exercises are small and manageable and drive the point home.
J***-1 like: Structured approach I like the hands on experience. Putting theory into practice helps reinforce the concepts
M***-1 like: Structured approach I think the TDD is good for us to have a different coding thinking. With the introduced procedure, it could be helpful to avoid some protentional issues.
M***-1 like: Structured approach The test cases help to refine the code structure and flow step by step. It improves the code quality and make it more stable.
M***-2 like: Structured approach The step-by-step approach. so that we don't skip or jump minor details
M***-2 like: Structured approach I feel that it helps to write the code logic in step by step manner so you will able to decode your code even after full logic becomes complex.
M***-1 like: Structured approach It's methodical and a consistent process
M***-1 like: Structured approach It is satisfying that once the code has been finished, the testing is too!
M***-1 like: Structured approach Eliminates analysis paralysis and provides clear path of what to do next in small digestible pieces.
M***-1 like: Structured approach Not much, I think it would work for GUI development possibly, I don't think it works for embedded development where there are more interfaces and the design is critical and should be done up front
M**-1 like: Structured approach structured way of working
M**-1 like: Structured approach Incremental development mind-set
M**-1 like: Structured approach Fast feedback
M**-2 like: Structured approach I like that the process is structured to slowly build the program through expectations of results. This seems like a more efficient approach than banging out code with hopes of expected returns.
M**-2 like: Structured approach I like the iterative approach in building functionality as I develop a similar way
M**-2 like: Structured approach Definitely liked working with a partner, helps things move faster.
M**-2 like: Structured approach I liked the exposure to creating test environments for a particular problem. The practice was very nice to have.
N/A like: Structured approach It makes you consider things step by step which helps to really consider the problem
N/A like: Structured approach I liked being able to methodically move from a requirement to a test (at least for this simple exercise)
N/A like: Structured approach How we solved one problem at a time
N***-1 like: Structured approach The code came together well at the end and you know it's decent code because it was tested
N***-1 like: Structured approach Very methodical and thought process is traceable assuming we use version control for intermediate checkins.
R**-1 like: Structured approach I like the structure coding approach TDD forces you to do so
R**-1 like: Structured approach Do not really know yet...
R**-1 like: Structured approach The structure makes sure I am less likely to forget steps/things
R**-1 like: Structured approach It seems to be a good way to cut a problem into "small pieces".
R**-1 like: Structured approach We have a very structured structure
R**-2 like: Structured approach Solve one problem after the other.
R**-2 like: Structured approach It made workflow how TDD should be done very clear
R**-2 like: Structured approach Interesting new approach, you need a new way of thinking
R**-2 like: Structured approach It makes you actually think about the outcome in advance, but step by step.
R**-2 like: Structured approach you work step by step; but it is a little bit "strange thinking" (its new)
R**-3 like: Structured approach It's structured and you dont jump right away to coding the first solution You think of the problems, which could arise in the first place You break down the solution and verify the step solutions
R**-3 like: Structured approach To have a concrete example on how to use TDD and practice it
R**-3 like: Structured approach To have a concrete example on how to use TDD and practice it
S***-1 like: Structured approach I like out tests build on each other to keep your code honest.
S***-1 like: Structured approach It's systematic in its approach.
S***-1 like: Structured approach I liked how you could start with very basic tests and make sure your initial thinking is correct for a structure and functions.
N/A like: Structured approach It forces me to take small, bite-size pieces of code instead of spending tons of time coding myself into a corner with no code that actually is good or works
N/A like: Structured approach I liked having (N) functionality confirmed before adding (N+1) functionality. It makes sense.
N/A like: Structured approach The cyclic framework (compiler fail, linker fail, test fail...) is simple and effective. Code written this way I feel is going to be robust, it has passed a minimum quality standard.
T*-1 like: Structured approach Good strategy to stepwise implement functionality
T*-2 like: Structured approach A structured way of working. Fits to my working style: do tiny steps, test them so that one can rely on them. Fake before make it a good style.
W**-22 like: Structured approach It forces me to think about other use case than only the use case I have at the time of writing a class.
W**-22 like: Structured approach With incremental coding comes very many successes! :)
W**-23 like: Structured approach I like the structure, such that progress is concrete.
W**-23 like: Structured approach If done in concert with a separate but conjoined design activity, TDD ensures that design intent is met
W**-24 like: Structured approach I liked that TDD forces you to examine the behavior before starting.
W**-24 like: Structured approach TDD is something that my group has been doing with a great amount of inconsistency, finding a method and sticking to it will be beneficial.
W**-24 like: Structured approach I liked that you incrementally build the functionality and are confident that your code works as you go along. You also have tests now that verify that you don't break things as you develop further.
W**-26 like: Structured approach It helps break the problem up into small steps and forces me to logically think through the code development.
W**-27 like: Structured approach TDD makes you think about HOW the design works and how it can fail
W**-27 like: Structured approach Very interessting, I definitely liked that the "API" is written before any code changes.
W**-27 like: Structured approach TDD makes you think about the code incrementally, making it easier to design correctly.
W**-27 like: Structured approach The way you think: making little increments from the simplest thing
W**-28 like: Structured approach I like how the code is being developed incrementally instead of all at once. It gives you time to be more thoughtful about the code at each step.
W**-28 like: Structured approach there is a certain structure of doing TDD that helps coding faster/easier to do and manage.
W**-28 like: Structured approach it's a nice methodical approach and ensures test development as part of the development; there is always something that can run
W**-29 like: Structured approach It's thorough.
W**-29 like: Structured approach Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough.
W**-29 like: Structured approach Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough.
W**-29 like: Structured approach Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough.
W**-29 like: Structured approach Building things around ADTs is an attractive approach and this feels like a good way to develop them incrementally without agonising over whether the interface is comprehensive enough.
W**-30 like: Structured approach I could TRY to ignore the future problems bouncing around in my head.
W**-30 like: Structured approach Test when passed, felt good. Liked how the small each of the steps were - seemed to break down the problem well.
W**-30 like: Structured approach I liked the idea of writing tests to.. well test all possible outcomes. I have realized that it's not only two outcomes. it was a great experience
W**-30 like: Structured approach Testing guides your code development.
W**-30 like: Structured approach Test code is clean.
W**-31 like: Structured approach This is straightforward method
W**-31 like: Structured approach Being able to build the interface in a very deliberate way, not getting caught up in implementation without knowing whether it works.
W**-31 like: Structured approach Makes you really stop to think about the requirements
W**-32 like: Structured approach I like that it forces you to focus on getting the results needed in a targeted fashion. I like that the work is done in small chunks.
W**-33 like: Structured approach I could keep getting distracted by interesting discussions with other people, but easily recover my train of thought, because I was focussing on a small incremental change
W**-33 like: Structured approach TDD definitely provide a disciplined approach that looks like it's worth the effort.
W**-33 like: Structured approach Presenting the theoretical approach and then providing hands on experience soon after is a great way for learners to immediately assimilate what the hell is going on.
W**-34 like: Structured approach That I have a structure for creating test cases.
W**-34 like: Structured approach Once you get into the routine, it's very methodical and iterative.
W**-34 like: Structured approach it is supposed to help me write code with less bug. But I have yet to experience that. But my first impression is that it also helps me structure my thoughts and methods and move more methodically
W**-34 like: Structured approach The TDD macros gave a nice baseline test environment.
W**-34 like: Structured approach I like that it forces you to be methodical when developing something from scratch. It promotes adding functionality in an incremental way from simple to complex.
W**-34 like: Structured approach TDD seems to inherently create well structured code. small bits of work during the coding process can replace a large portion of work that would normally come after the fact.
W**-34 like: Structured approach The production code is easier to read.
W**-34 like: Structured approach Having the tests as specification is great! I looks that anybody can understand it if I stick to the discipline of one test per minimum behavior.
W**-34 like: Structured approach Having the tests as specification is great! I looks that anybody can understand it if I stick to the discipline of one test per minimum behavior.
W**-35 like: Structured approach attacking/focusing on a small piece of the entire problem at a time enables regression test along the way of making new changes
W**-35 like: Structured approach the camaraderie of thinking together -- we paired in -- to systematically think through a problem.
W**-35 like: Structured approach The step-by-step methodology allows complex code development over time, and I can see immediately why this is widely used.
W**-35 like: Structured approach Not having to think too hard between tests - just make the next test pass, the hard thinking is all done in *making* the test.
W**-35 like: Structured approach I enjoyed the familiar pattern that TDD creates for someone new to the language and procedure of testing. It makes it easy to not get lost and incrementally make progress.
W**-36 like: Structured approach I liked that it made it easier to create the final product from scratch. There were clear cut goals to complete.
W**-36 like: Structured approach It's a way for methodical progress and provides a safety net.
W**-36 like: Structured approach I like the progress of failing, then passing, then failing again... seeing the steps back and forward as things are sort of correct, then catch logic issues.
W**-37 like: Structured approach It was a good way to force me to break down the problem, and solve it in pieces.
W**-37 like: Structured approach It forces you to deconstruct what you are trying to do.
W**-37 like: Structured approach * Is a new design philosophy, that improves the development process and the system safety.
W**-37 like: Structured approach I liked the simplicity of it. It breaks it down to super simple tasks that you check very quickly. I do think that with practice, the flow of creating tests will become more natural.
W**-37 like: Structured approach The "fake it till you make it" approach made it more apparent when you needed to add something. I focused on passing the test and knowing if it was moving in the right direction.
W**-39 like: Structured approach Following a algorithmic method for implementation is helpful, especially at this early stage in my TDD understanding.
W**-39 like: Structured approach Learning a more structured way of coding
W**-40 like: Structured approach Simple to follow process.
W**-40 like: Structured approach It helps me avoid "analysis paralysis". When I'm focusing on one test at a time, it is easy to make a quick note for a later test and focus on the task at hand.
W**-41 like: Structured approach I liked making the incremental tests pass and adding functionality as it was necessary.
W**-41 like: Structured approach TDD is good and is allowing us to work in groups. Learning about the Unit testing is also good so far. The platform is pretty good as well.
W**-41 like: Structured approach After implementing some features, you realize that bugs will show up in the following tests due to "bad implementation" of your solution.
W**-41 like: Structured approach It is hard to frame test cases initially, but I believe it has a structured approach that eliminates many loopholes.
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.
B**-1 like: Systematic Methodical approach
B**-1 like: Systematic A systematic approach
W**-19 like: Task Creation Breaking down a large task into multiple smaller tasks
W**-19 like: Test Coverage The test coverage you're left with once complete.
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
V****-2 like: Test while develop I liked the idea as it allows you to test while you are developing your module.
Z**-1 like: test-coverage TDD results in small, well-tested units of code. Good tests and code coverage happen naturally.
B***-1 like: test...test forces you to test your implementation while you develop the interface for your code.
C**-1 like: Testability Makes you think about development step by step and each part is proven with a new test.
C**-1 like: tests Tests are present for functionality.
Z**-1 like: testthetests I like that it "tests the tests" by ensuring they can fail.
B***-1 like: think Makes you stop and think about how your implementation will work before you actually implement it
F**-1 like: think corner cases We can think about corner cases before writing code
T***-1 like: this this and that
B***-2 like: Thorough The emphasis on failing early and often.The incremental approach to building tests.
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.
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.
V**-1 like: time saving saves time otherwise spent debugging
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
V**-1 like: Traceable it is easier to trace where we went wrong in the code. and took less time to fix it.
C*****-2 like: tricking tests The exercise we performed demonstrated the importance of writing test sets that can't be tricked into passing.
C*****-2 like: unbiased Testing is considered upfront before any code is written.
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**-21 like: Understanding It brought attention to logic errors early on, and provides a better understanding of how/why sections of code work.
T**-1 like: Unsure I don't know enough to know what I like about it just yet.
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.
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.
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
V****-2 like: Useful-test-platform Reduces future debugging efforts, able to catch the bugs early.
D****-2 like: usefull It catches design problems and logical errors early before they become baked into the code
B**-1 like: validation validation will drive the implementation, not the other way around
C*****-2 like: validation It is great seeing confirmation that the code you're writing is working as you're writing it.
B***-2 like: warm fuzzies That your velocity increases as your body of written tests grows, and you get more warm fuzzies.
M***-1 like: way to go helps to make code more robust
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"?
F**-1 like: wonderfull I like the way to step by step implement a complex feature with test case for each step.
F**-1 like: workflow The course will teach people how to perform unit test, integrated test, system test.
T**-1 like: working The ability to keep code working.
F**-1 like: Wow Should think about the system before start writing code. write and test continuously.
B***-11 like: YAGNI Helps with YAGNI because I can't write code if it doesn't have a test