What 976 people liked about their first TDD experience

Course code Kind In a Word 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
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.
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.
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.
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***-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.
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.
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
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***-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
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.
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***-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
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
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**-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
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.
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***-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
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.
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
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.
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***-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.
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.
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