What 1218 people liked about their first TDD experience

Summary selected Impressions
like: "secure" I liked that everything is supposed to be and keep working regarding the continuous requirements on the way to MVP
like: 851 like 851 -- revised, again, and once more
like: accomplishment gives you sense of accomplishment.
like: agile The concept of devloping and testing in small increments, its like Agile, aka iterative waterfall :)
like: Ahhummm This first exercise ran smoothly
like: All the above. It's fun to see the output of your changes right away in a very easy, simple-to-digest, form.
like: All the above. Instant feedback with checks for memory leaks enabled.
like: All the above. Hands on exercise is useful
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.
like: All the above. Iteratively and incrementally the solution evolves.
like: All the above. - 100% test coverage achieved automatically - interface written from user perspective - no feature creep
like: All the above. - TDD forces a structured buildup of your implementation - When done right, it results in 100% code coverage
like: All the above. I like that the code grows organically and all paths are tested and no unneeded code is written.
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.
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.
like: All the above. Good coverage. Easily identify issues.
like: All the above. Structural Approach. One step at a time
like: All the above. I like the flow of TDD. Small incremental steps.
like: All the above. I like being able to see pitfalls in my code by my previous tests. Being able to see how my code has adapted to fit a current need, but also allows me to know what mistakes I have made.
like: All the above. cooperation with Ivo :)
like: All the above. color icon
like: All the above. I can see how the code written is really what you want it to do.
like: All the above. DEMO
like: All the above. problems can split down to smaller pieces which is easier to focus and get things done
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.
like: All the above. It help to find bugs at very early phase of development.
like: All the above. It help to find bugs at very early phase of development.
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.
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.
like: All the above. It helped me to be more structured & tackle the big problems by one step at a time approach.
like: All the above. I like the approach to move from simple to complex step by step
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.
like: All the above. switching between test mind set and development mind set
like: All the above. I like that, TDD give understanding that, we can test the code at early stage of development.
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
like: All the above. It is a step by step process to develop and test code.
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.
like: All the above. I liked the immediate feedback and focus on the code as it is being written.
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.
like: All the above. TDD helps you to avoids errors already during implementation.
like: All the above. I enjoy exercices
like: All the above. Seeing code and tests evolve together
like: All the above. Another method of writing code.
like: All the above. It makes you focus on one thing at a time.
like: All the above. I liked that a data structure useful in real life was developed instead of developing some trivial toy code.
like: All the above. The low barrier to entry and the fact that it's somewhat self-documenting.
like: All the above. I like that it quickly helps hash out the interfaces and prevents simple errors.
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.
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
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
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
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
like: All the above. Being in the flow, quick feedback, reduced cognitive load.
like: All the above. starting with test cases before designing and implementing is interesting and the experience is new to me
like: All the above. easy to focus one thing
like: All the above. Its very simple yet can help spot nasty bugs early. Its quick.
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.
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.
like: All the above. Very efficient use of time. Nice quick way to start implementing a design without overthinking it.
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.
like: All the above. I like the focus on a smaller problem first. Kinda like putting a puzzle together
like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
like: All the above. I liked that Code Dojo yelled at me when I got ahead, and helped me start getting into TDD
like: All the above. Testing documents the API, the parameters and the usage of the module.
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!
like: All the above. I really like, the simplicity and efficiency. It barely takes times to correct an error. Fast feedback.
like: All the above. locking the functional behaviour and incremental development approach
like: All the above. Very practical, and fun.
like: All the above. Writing tests first and forcing you to slow down. Prevents you from getting ahead of yourself.
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.
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.
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.
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.
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.
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.
like: All the above. Systematic, methodical, pragmatic, safe progress
like: All the above. Systematic, methodical, pragmatic, safe progress
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.
like: All the above. I like to keep mastering my code behaviour while gaining the freedom to refactor it at will
like: All the above. I like to keep mastering my code behaviour while gaining the freedom to refactor it at will
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
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. :-)
like: All the above. Easier to find out what are the next steps.
like: All the above. Test cases are written before write the code, test are simples and makes less bug in code.
like: All the above. I like wingman-sw.com interface very understandable.Also gather.town has good feature!TDD is good!I didn't think about final production code because it happened automatically when you pass tests!
like: amazing Help me to have a mindset on how to test code during development
like: Amazing The training is amazing! I like the learning method (nice presentation + practical excercies) to understand TDD better
like: architecture Test driven architecture: The architecture of your code becomes testable and arguably better
like: assurance I like the assurance I get that my code is working properly
like: automated Get automated test results for changed code
like: Automation Testing is done for you.
like: average Make me think more carefully during the coding process. But it takes time to get familiar with.
like: avoid bugs I can reduce the chance of creating bugs.
like: avoid bugs I can reduce the chance of creating bugs.
like: Basic It reminds me "Back to Basic"
like: bite-sized Small steps: I like that each step is small, minimizing cognitive load
like: BLUE-1 BLUE-1 Test Comment
like: careful It helps me think more careful about my code
like: clean Encourages removal of cruft and unnecessary features
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.
like: co-development Encourages thinking about how code should be tested while developing
like: code overview Force me to rethink what I have implemented.
like: coding I like change signal red or yellow to green (coding with test)
like: collaboration collaboration and support
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.
like: concentration I can focus on each test step when writing codes.
like: Concise I like the idea of working on one problem at a time (small structured approach).
like: Concreteness In the absence of Dijkstra's mathematical proof, the approximation to a proof that your code is correct
like: confidence I like that I can be confident that new changes haven't broken functionality that has already been tested.
like: Confidence Having a large bank of tests is reassuring when making large changes.
like: Confidence I feel more confident that my software is fully functional when I have a suite of tests that pass.
like: confidence refactoring with confidence from known working code and test == good
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.
like: Confidence Creates confidence about the code being developed.
like: confidence I liked the confidence of knowing that the code worked and that I didn't break things that used to work.
like: confidence You can add new features with more confidence that prior functionality will not get broken, since your old tests continue to pass
like: Confidence TDD gives you confidence about your code.
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.
like: confidence I am able to gradually build something big step by step and I know for sure the part I tested will work.
like: Confidence that my code works When we changed some of the implementation, previous tests failed pointing out some things we forgot. Also changing the code feels "safe" since we know that previous functionality is covered by tests
like: Confidence that my code works More structure way of writing code.
like: Confidence that my code works More structured way of coding
like: Confidence that my code works It makes sure that every line you write is tested
like: Confidence that my code works While you progress, you can check that the basic functionality that you already programmed didn't break.
like: Confidence that my code works I liked creating code increasing its complexity
like: Confidence that my code works Easy to test that the code you've written works
like: Confidence that my code works Refactoring. See the tests pass.
like: Confidence that my code works Easy to test code without hw. Forces you to create a properly defined interface
like: Confidence that my code works Forces focus on interface and gives you coverage on refactoring
like: Confidence that my code works Forces focus on interface and gives you coverage on refactoring
like: Confidence that my code works Focus on testability of design
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.
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.
like: Confidence that my code works Positive affirmation that was is expected is delivered.
like: Confidence that my code works Made me confident to change my code
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.
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.
like: Confidence that my code works Thinking about production code incrementally
like: Confidence that my code works The functions you write might have surprising behavior and the test helps to identify it
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.
like: Confidence that my code works I liked that it keeps you from breaking things when you change your code later on.
like: Confidence that my code works It helps to incrementally proceed with the logic implementation . And helps to adress new usecases as we proceed.
like: Confidence that my code works It helps to incrementally proceed with the logic implementation . And helps to adress new usecases as we proceed.
like: Confidence that my code works Breaking down the requirements made it easy to implement the logic
like: Confidence that my code works It catches regression errors
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
like: Confidence that my code works It is iterative and gives opportunity to find bugs
like: Confidence that my code works TDD is finding bugs early and we can rework our code without worrying about introducing new bugs
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
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.
like: Confidence that my code works writing tests as your write code, results is less defects later.
like: Confidence that my code works writing tests as your write code, results is less defects later.
like: Confidence that my code works I felt like I knew what was going on exactly at each step as opposed to assuming things will work. Its reassuring to know your code is going to work
like: Confidence that my code works like like
like: Confidence that my code works It made me thing more about how functionality could fail in each small part of a codebase and how to test it, making me more confident the code will (hopefully) always work when complete.
like: Confidence that my code works Know code works continually
like: Confidence that my code works I feel more confident to refactor / optimize the tested class
like: Confidence that my code works I liked the fact that the code is easier to be maintained and refactored
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
like: Confidence that my code works Greater confidence that my code works as expected.
like: Confidence that my code works Provides immediate indication if your tests are being passed or if you broke a previous test.
like: Confidence that my code works Minimize future issues.
like: Confidence that my code works Great exercise to understand how to build up a test driven design.
like: Confidence that my code works easier to troubleshoot. feel confident to re-structure the code.
like: Confidence that my code works High test coverage
like: Confidence that my code works High test coverage
like: Confidence that my code works New experience, never had idea we can write test first before we implement the code.
like: Confidence that my code works Having the test suite at the end to provide a safety net when refactoring code.
like: Confidence that my code works I liked the increased confidence in my production code and the safety net for refactoring
like: Confidence that my code works I like being able to break the problem down into smaller pieces.
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.
like: Confidence that my code works I saw the benefit of establishing a cadence and rhythm to writing the test then the code. Smaller discrete tests did catch issues and proved the overall concept was working before adding new function
like: Confidence that my code works It was useful setting up explicit behavior in the UT and then writing the code to implement that behavior with the test to then check you did it correctly
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.
like: Confidence that my code works It helps to test code properly.
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.
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.
like: Confidence that my code works It forces me to double check my logic and ensure fatal mistakes aren't introduced early on.
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.
like: Confidence that my code works TDD allows us to plan out the features before implementation
like: Confidence that my code works Provides confidence that code is working as expected, even after changes are made.
like: Confidence that my code works Being able to test each minor implementation as you develop is great for confidence in the code.
like: Confidence that my code works * Building in small increments * Confidence your code is behaving as expected as you move forward
like: Confidence that my code works Having to verify that the test fails before you right code so you know that your code makes a difference when the test passes.
like: Confidence that my code works I liked being able to easily verify our functions with the implemented tests already in place.
like: Confidence that my code works I liked that we were able to do some hands on programming. I thought it was helpful that we were able to work in the classrooms.
like: Confidence that my code works Well tested code. Tests written can be reused for automation testing. Relatively simple at first.
like: Confidence that my code works I like being confident that my code works
like: Confidence that my code works Interactive and live environment to build as we go...
like: Confidence that my code works Felt safe refactoring when I needed to go back and change something.
like: Confidence that my code works can see the code growing in a controlled manner
like: Confidence that my code works can see the code growing in a controlled manner
like: Confidence that my code works Safety of refactors knowing that the functionality is tested
like: Confidence that my code works I don't have to think about my change breaking something else, my tests do that for me.
like: Confidence that my code works Step-by-step, incremental building of a growing structure
like: Confidence that my code works Introduction with an practical example
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
like: Confidence that my code works It is an excellent tool for refactoring.
like: Confidence that my code works caring about bugs before programming the code makes me feel safe.
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).
like: Confidence that my code works We feel safe while implementing the functionalities or refactor the code.
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.
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.
like: Confidence that my code works I like the TDD forces me to slow down and carefully consider each step.
like: Confidence that my code works Peace of mind that the behaviors asserted by past tests will be maintained while we add more behaviors.
like: Confidence that my code works A bug fix has always lead to opening up another resolved or new bug. TDD keeps my confidence high that I don't add bugs to existing code.
like: Confidence that my code works TDD gives me confidence both on writing a better implementation and to change it in the future without the fear of messing it up.
like: Confidence that my code works impressive
like: Confidence that my code works Yeah, I like it because I will not only have fewer bugs, but it also helps me make changes to my codes more confidently.
like: Confidence that my code works I like that small increments are known to work before moving on to additional functionality, and indication that my changes did not "break" previously working code.
like: Confidence that my code works Its very good at verifying behaviors of code and ensuring code reacts as expected.
like: Confidence that my code works - Tests are clearly designed and explained.
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.
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.
like: Confidence that my code works A new vision to deal with the problem and have it working step by step.
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.
like: Confidence that my code works It designs the tests ahead of the code.
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
like: Confidence that my code works Confidence that new code won't break the behaviour already done.
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.
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.
like: Confidence that my code works Small changes and test every line of code that is being written.
like: Confidence that my code works It is very easy to implement from the get-go.
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
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.
like: Confidence that my code works Never being very far from code that works.
like: Confidence that my code works It gets a designer to think a little harder about implications of a line of code
like: Confidence that my code works I like the feedback the tests provides when refactoring the code
like: Confidence that my code works It's easy to play around with alternative implementations without starting from scratch.
like: Confidence that my code works Building on past success
like: Confidence that my code works Able to validate code as it is written.
like: Confidence that my code works The guarantee that the behavior of previous tests is still in the code
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.)
like: Confidence that my code works I liked that my code told me when I broke it
like: Confidence that my code works Mandates me to write unit test if I use TDD approach
like: Confidence that my code works When modifying previous code, less fear of breaking already testable behavior.
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.
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.
like: Confidence that my code works TDD emphasizes the importance of tests as much as the importance of code.
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.
like: Confidence that my code works Refactoring an implementation detail and knowing that nothing existing broke is great
like: Confidence that my code works I like that in then end there will be a fully functional test to go along with code
like: Confidence that my code works I had a safety net when refactoring
like: Confidence that my code works The safety net
like: Confidence that my code works That the code is fully tested when you go to release it.
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.
like: Confidence that my code works The tests verify that the code works.
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.
like: Confidence that my code works Nice to see the details.
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
like: Confidence that my code works The ability to continue testing new code, with the previous tests running every run.
like: Confidence that my code works It feels like I'm experiencing programming for the first time. It's the same sensation of power!
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.
like: Confidence that my code works The requirements must be understood before you write tests.
like: Confidence that my code works I liked how the functionality increased and i was always sure that what we did still works.
like: Confidence that my code works Forces a deterministic methodology for developing robust software.
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
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.
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
like: Confidence that my code works Guides the development clearly Satisfying seeing tests pass Previous tests can fail when implementation changes so prevents regressions
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
like: Confidence that my code works Many serious, hard-to/debug, bugs can be avoided if done correctly
like: Confidence that my code works Many serious, hard-to/debug, bugs can be avoided if done correctly
like: Confidence that my code works Ability to refactor with a "safety net."
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.
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.
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.
like: Confidence that my code works Writing the test first and then the function makes it clearer about the function's purpose
like: Confidence that my code works Writing the test first and then the function makes it clearer about the function's purpose
like: Confidence that my code works Write minimum code just to pass the test.
like: Confidence that my code works It forces you to think a different way of programing. Go step by step (fail and pass)
like: Confidence that my code works Even when changing the underlying implementation, you don't have to worry about the functionality
like: Confidence that my code works I have a certain security when changing/extending/reworking my code at a later time.
like: Confidence that my code works Structured approach of doing test Fun way to code
like: Confidence that my code works TDD helps clarify requirements and design before coding. The immediate feedback from tests made it easier to catch and fix bugs early in the development process.
like: Confidence that my code works It forces you to work in little chunks which helps you catch errors as you make them. You have a net of tests to fall back on when you make new changes.
like: Confidence that my code works I enjoy that you only write the code you are going to test at the time, removing some questioning of what code is needed and what isn't at most points.
like: Confidence that my code works I use TDD regularly. I like having the proof that the code works within known limits.
like: Confidence that my code works Previously I wrote some functions and tried to think about test-scenarios for them. By separating tests - one small test for one behaviour, then implementation I am sure that there's no untested code.
like: Confidence that my code works The atomisation of the development process. Given a general specification, we start building up from the simplest and smallest piece to the more complex. It allows you to take safe steps.
like: Confidence that my code works hey hjey
like: Confidence that my code works a like
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.
like: consistent behavior It helps to secure that existing code works when making changes or refactoring.
like: control More control on production code
like: Convenient It's nice being able to move on after a test knowing that the code is set up to work correctly.
like: Correction Checks all the input conditions for the functions.
like: coverage Easy way to get full functional 'coverage'
like: coverage All possible situations are tested
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
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.
like: definitions It helped really define the class interface before actual implementation was required.
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.
like: deterministic converts hidden test and debugging time into actual measurable (and very long) deterministic development/ testing time
like: different Provides a different way to view development.
like: Discipline Practicing the mental habit of making a "hard" specification before writing the code
like: done Tests are done when you are.
like: driven-by-goals can incrementally build towards requirements and desired features via tests
like: driven-by-goals can incrementally build towards goals and requirements via tests
like: ease-of-use Seems to be relative easy to use once we get the hang of it.
like: Easier Just easier to debug and check my function. It helps me to be carefully to write code.
like: easier testing Made testing code easier.
like: easier-tests It was easier to think about tests that needed to be written.
like: Easy TDD is much easier than I tought.
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.
like: Efficiency I think TDD is enable the development quickly and efficiency.
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.
like: Efficient A methodical process to build robust code and develop a based of test cases.
like: efficient The quick feedback about our code.
like: effort Forces you to think about developing in a different, initially less comfortable way.
like: effortless I ended up with a mostly well tested code, without thinking about testing it in post.
like: encourage I like the improved quality.
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.
like: error proof? avoid chance to make mistake, errors
like: Everything Everything.
like: everything what;'s not to like. some other stuff, and even more now. now what. and another line And then some
like: exceute I like the way of writing our own test cases to check the code
like: Expansion I like the different outlook on the coding. It creates a different way of thinking
like: Expectation You tend to think more about the expected outcome before make changes.
like: failure Ensuring the test fails is important - protects against poorly written or mis-targeted tests
like: Fast Fast development cycle Immediate conformation that functions are working Test case implementation is not pushed to the end of implementation.
like: Fast feedback Gives a scaffolding for building software
like: Fast feedback Test as you go. Could implement ready test.
like: Fast feedback The perspective is forced to expected behaviour first and then to internal functionality.
like: Fast feedback Many test cases ready before actual code is ready
like: Fast feedback I like that I can test my code often and fast. Before, I only did manual testing and that took time and I could't do it very often. I had low confidence that my code actually worked.
like: Fast feedback Makes you think deeper about coding a module
like: Fast feedback Think "not happy path" from the start
like: Fast feedback When a refactor broke something, you find out immediately.
like: Fast feedback Instant response while testing Fairly simple when explained
like: Fast feedback Structured development process, rapid feedback on errors
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.
like: Fast feedback Like the routine of create test, make it build, make it fail, make it pass. Repeat. It is a nice workflow.
like: Fast feedback xxxx
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.
like: Fast feedback Nice modular work.
like: Fast feedback Very fast feedback loop code->testing
like: Fast feedback simple and quite straight forward
like: Fast feedback it forces us to think about every step of code development
like: Fast feedback Writing code incrementally; it made identifying errors easier.
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
like: Fast feedback not much
like: Fast feedback Its good to see you your code get matured with test we execute.
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
like: Fast feedback Quick feedback, seeing quickly where I failed and how.
like: Fast feedback I liked making changes in very small increments and getting immediate feedback on my code, then I don't get lost in what caused the error.
like: Fast feedback clear goals was nice with an iterative process
like: Fast feedback Lots of interaction with the code, compiler, testing. More like a dialog than an essay.
like: Fast feedback It was fun to do this again as I have not done this in a long time.
like: Fast feedback Having the code pass the tests made me feel good. I also liked the fact that all the tests add up to a complete feature checklist.
like: Fast feedback quickly verifies test cases
like: Fast feedback quickly verifies test cases
like: Fast feedback How fast it was to get a test result (red/green) after doing a code change.
like: Fast feedback test
like: Fast feedback test
like: Fast feedback It is fun to see tests pass and have them there easily identify which changes work and which ones don't
like: Fast feedback Make complexity into simple and atomic steps
like: Fast feedback fast feedback and know that it does what is suppose to
like: Fast feedback I liked how quick the feedback was for "Your implementation was wrong".
like: Fast feedback I know immediately if there are issues
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".
like: Fast feedback This is me
like: Fast feedback I know immediately if there are issues
like: Fast feedback See errors very soon after writing the code
like: Fast feedback I liked the feedback in the process. It's always nice getting a green bubble.
like: Fast feedback trest like
like: Fast feedback james test
like: Fast feedback james test labc-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.
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.
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.
like: Fast feedback Helps find the issues with our code faster.
like: Fast feedback Helps in identifying the bugs early on during the development stage.
like: Fast feedback I like that I can add new features and test that all other things work properly.
like: Fast feedback I liked the immediate and tactile feedback that TDD offers
like: Fast feedback Immediate feedback, iterative development.
like: Fast feedback Immediate feedback, iterative development.
like: Fast feedback Very closed loop iterative approach
like: Fast feedback Very closed loop iterative approach
like: Fast feedback I like the variety of material. The shared space is kind of fun too.
like: Fast feedback You find out very quickly if a new change works. You find out just as quickly if it breaks something unexpected.
like: Fast feedback testr like
like: Fast feedback test test
like: Fast feedback Good practical learning experience.
like: Fast feedback Hands-on experience
like: Fast feedback I like how we can know what was wrong with the code instantly
like: Fast feedback I like that you do things incrementally and you start off with the most simplest solution by just hard coding values and then move to more intricate solution.
like: Fast feedback I liked building simple steps at a time. It makes it feel like you are making progress on problems and having the tests as a safe cushion as you make new behavior is good to have.
like: Fast feedback Mistakes or changes that cause issues with other tests immediately revealed.
like: Fast feedback hey what are you saying
like: Fast feedback I like the building up of the design based on passing small tests for behavior.
like: Fast feedback I like the quick feedback about my code
like: Fast feedback Learning to code in incremental steps which helps in early bug detection
like: Fast feedback I like the time between the tests failing and tests passing.
like: Fast feedback makes programming simpler. you know what you have coded so far works.
like: Fast feedback I like TDD calls for small incremental changes, limiting how many things can go wrong at the same time
like: Fast feedback Step-by-step, incremental building of a growing structure
like: Fast feedback Complete new way of thinking about writing functionality
like: Fast feedback if you invest time writing tests beforehand, it gives fast feedback if methods/code do as intended..
like: Fast feedback Fast response and easy refactoring Quick results
like: Fast feedback Immediately find stupid errors (e.g. off-by-one) using trivial testcases that seem to simple to write usually
like: Fast feedback I like that you can test small code snippets following a fixed skeme
like: Fast feedback New added functionality is tested against all finished, completetd tests
like: Fast feedback Its a good concept to minimize bugs. You can see how your changes impact earlier tests.
like: Fast feedback Test results are showned quickly and code regressions can be detected.
like: Fast feedback Small groups and individual process
like: Fast feedback I like the instant feedback and I only wrote code I needed.
like: Fast feedback It was methodical and immediately let you know if something broke while adding new features.
like: Fast feedback I like the inherent incremental and iterative development
like: Fast feedback I like the fast and constant feedback that keeps me in check and my errors to as small as possible
like: Fast feedback I liked working in small steps and receiving feedback for the small steps.
like: Fast feedback constructed step by step development.
like: Fast feedback more or less easy to understand how it works
like: Fast feedback - can check source quickly - can tell us if code is uncovered
like: Fast feedback good exercise implementation on webpage
like: Fast feedback 'only code what you need in that moment' has fast progress while coding
like: Fast feedback fast environment with immediate feedback
like: Fast feedback Find quicker and earlier bugs in the code.
like: Fast feedback If you understand the procedure, the examples are a nice exercise.
like: Fast feedback Code is being tested while implented.
like: Fast feedback I like the iterative approach. Catching errors early and getting ideas for what could go wrong, before even implementing it
like: Fast feedback simple approach to breaking down a problem
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.
like: Fast feedback Reduce the bugs and will not miss the functionality
like: Fast feedback I like that I can get immediate feedback on the performance and behavior of the code that I'm developing
like: Fast feedback Creating code that progresses in complexity across multiple functions as oppose to fully building out one function at a time
like: Fast feedback It shows you something went wrong immediately
like: Fast feedback old mac
like: Fast feedback new mac
like: Fast feedback old 1
like: Fast feedback new 1
like: Fast feedback old 2
like: Fast feedback hey 1
like: Fast feedback hey 2
like: Fast feedback hey 3
like: Fast feedback like 1024
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.
like: Fast feedback test 1
like: Fast feedback test 3
like: Fast feedback test 4
like: Fast feedback test 5
like: Fast feedback fun
like: Fast feedback I like having the automated tests to catch when I make a coding mistake.
like: Fast feedback There is fast feedback when things are broken.
like: Fast feedback New ways to think on coding with test in minde
like: Fast feedback I don't deep into the problem before I can find it.
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.
like: Fast feedback Testing interleaved with development. Instant feedback.
like: Fast feedback When I do break testable behavior, I find out immediately, when I still remember the changes I was making.
like: Fast feedback I said this already, but the framework is pretty easy to work with.
like: Fast feedback I liked that I was forced to test one thing at a time
like: Fast feedback Find errors with the code almost instantly.
like: Fast feedback I liked seeing instant results to my failing tests after making them pass.
like: Fast feedback The confidence that when something is done it is truly DONE.
like: Fast feedback Start making progress right away - no analysis paralysis.
like: Fast feedback Short, fast iterations.
like: Fast feedback Fast feedback
like: Fast feedback Getting a pass/fail straightaway is refreshing.
like: Fast feedback I liked getting instant feedback about small changes
like: Fast feedback web-30
like: Fast feedback Fast feedback
like: Fast feedback Getting immediate feedback when I make an error
like: Fast feedback Like the small steps.
like: Fast feedback There was instant feedback on how my code was working
like: Fast feedback Error analysis and possible maintenance work are easier and faster
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.
like: Fast feedback I like the granularity; it helped me stay productive without overthinking (or thinking too far ahead of where I was at).
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.
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.
like: Fast feedback I liked that I got incremental feedback without having made too many changes at once and having to backtrack.
like: Fast feedback Fast feedback loop: Error is usually only a few clicks away.
like: Fast feedback systematic safer way forward
like: Fast feedback Quick feedback if the code works
like: Fast feedback immediate response to small code change
like: Fast feedback A new approach to get solid code.
like: Fast feedback Making the test prior to the implementation gives a good feeling in terms of "My code is already passing the tests".
like: Fast feedback You get to see that you have introduced a bug or broken something almost immediately.
like: Fast feedback Loved small increments.
like: Fast feedback I like that I got feedback on issues I would not have typically seen so early in the development process.
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!
like: Fast feedback Small incremental steps that drive design.
like: Fast feedback james test
like: Fast feedback The pace is adapted to the people taking the course and the guidance is excellent.
like: Fast feedback The exercise is interesting
like: Fast feedback The exercise is interesting
like: Fast feedback We have found multiple issues with the code as we progressed. Without TDD this would not have been possible.
like: Fast feedback tests ware already sketched
like: Fast feedback Progress is fast, especially when pair programming
like: Fast feedback Ability to test each step of the way. If we design the test flow right, I can see how we can build a strong foundation
like: Fast feedback I liked the fact that TDD allows me to develop and validate my code iteratively in small increments. This seems to reduce the scope and time when debugging issues in the code.
like: Fast feedback Code can be built by starting small and in small increments, with quick feedback and bug discovery.
like: Fast feedback loop - Help break down the development process into smaller steps - Immediately test the code that i write. Fast feedback.
like: Fast feedback loop - Help break down the development process into smaller steps - Immediately test the code that i write. Fast feedback.
like: feedback I like the fast feedback loop. You're compiling and running very quickly after you start.
like: Feedback Quickly able to verify changes didn't break previously working features.
like: feedback quick feedback when a change broke something
like: Feedback responsive , feedback
like: feedback Quick feedback for both my successes and failures.
like: Feedback Fast feedback. It's rewarding to get lots of successes
like: feedback It gives rapid feedback, allowing you to see what mistakes you've made almost as soon as you've made them.
like: feedback I like building up quick wins. I know I'm making progress.
like: Feedback Fast feedback from tests about what does and doesn't work in the implementation.
like: feedback I like that it provides quick feedback as I'm writing code.
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.
like: Feels confident Gives enough satisfaction about the code written.
like: FewerBugs It is easy to trace
like: Find problems quickly I liked having to learn to write the test before the code - very difficult at first but definitely started feeling the cadence.
like: Find problems quickly It is nice to see the progression in small steps. Less errors and refactoring each time between tests.
like: Find problems quickly Tests are being developed at same time as code. Tests can catch issues earlier.
like: Find problems quickly Writing test first gives clarity on what is expected from a specific method. It feels safer to refactor and implement something new to the method if you have already tests in place.
like: Find problems quickly I did catch some small mistakes fast.
like: Find problems quickly New possible errors not known befire testes.
like: Find problems quickly I feels that it is much more complicate to enter a bug.
like: Find problems quickly I like that you feel that what you are coding is more robust and bugless
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
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.
like: Find problems quickly I like to have a process to follow which should help to avoid making mistakes.
like: Find problems quickly I liked that you see when changes makes old tests fail.
like: Find problems quickly "automatic" bugfixing
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
like: Find problems quickly Incrementally driving code with tests helps to find issues quickly.
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
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
like: Find problems quickly Test as you build
like: Find problems quickly Forces a different way of coding to look for a problem before adding/fixing it.
like: Find problems quickly I like that when refactoring the code, previous tests fail when something not updated correctly.
like: Find problems quickly Already existing tests helps to avoid mistakes during development
like: Find problems quickly It does seem to lead to a small steps with with success approach.
like: Find problems quickly The ability to create more methods with the confidence my previous methods worked.
like: Find problems quickly Test each feature as you build it, rather than building a list of things to test later. Should be good about enforcing explicit testing of edge cases, buffer overflows, etc.
like: Find problems quickly It forces me test and compile often which helps with finding problems.
like: Find problems quickly constantly checks that test cases are passing
like: Find problems quickly It's a very methodical framework that inspires confidence in early development. My partner and I have been catching errors a lot sooner than I normally would in my traditional development.
like: Find problems quickly Simple, step-by-step procedure to write bug-free code.
like: Find problems quickly I liked making the tests work as we built new functionality.
like: Find problems quickly I liked the feedback loop to continuously improve the development.
like: Find problems quickly I can find problem and debug quickly.
like: Find problems quickly I can find problem and debug quickly.
like: Find problems quickly I can find problem and debug quickly.
like: Find problems quickly step by step testing and found out the problem, in the end create the fully test.
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.
like: Find problems quickly It's interesting class, we can write the code and debug together.
like: Find problems quickly It makes the debugging easier and I can find the defects earlier.
like: Find problems quickly test test test
like: Find problems quickly I like the benefit of finding and resolving bugs faster with TDD approach.
like: Find problems quickly Helps find code shortfalls quickly.
like: Find problems quickly Keeping things simple in unit tests saves a lot of time giving the same quality of test case. DTSTTCPW
like: Find problems quickly it may minimize coding mistakes/bugs earlier on
like: Find problems quickly it may minimize coding mistakes/bugs earlier on
like: Find problems quickly TDD can detect potential bugs and test functionalities of methods in advance.
like: Find problems quickly TDD can detect potential bugs and test functionalities of methods in advance.
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.
like: Find problems quickly TDD is awesome. TDD forces us to think how software can fail.
like: Find problems quickly TDD is awesome. TDD forces us to think how software can fail.
like: Find problems quickly How progressive it makes the coding process and that when you jump the gun, you see what breaks.
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.
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.
like: Find problems quickly Immediate failure feedback on previous tests
like: Find problems quickly Small steps for easy debugging
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.
like: Find problems quickly I enjoy how TDD helps you find problems quickly and easily. I don't have to second-guess whether I accounted for all edge cases or properly formulated my condition - I can just quickly test it.
like: Find problems quickly I like that it finds potential errors that are independent to the source code early on. I can see it saving some time digging through what is causing failures.
like: Find problems quickly Quickly offers feedback on problems and where to look to fix them.
like: Find problems quickly Focused attention on implementation explicitly as a step by step approach.
like: Find problems quickly The tight loops helped debug the code quicker.
like: Find problems quickly The accumulating tests let you know right away when you introduce bugs.
like: Find problems quickly I liked that it can be a bit more organized when building code, you don't wait until the very end to find your problem
like: Find problems quickly I like the concept of TDD but I have problems with C++ as well as the learning environment.
like: Find problems quickly this is a test
like: Find problems quickly Catching errors quickly
like: Find problems quickly Small changes let you find the problems quickly.
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.
like: Find problems quickly Easy to track down the issues
like: Find problems quickly Since we work step by step, we find the problem more quickly
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.
like: Find problems quickly it makes testing easier and debugging faster
like: Find problems quickly Structured development process
like: Find problems quickly jsdl;kfjsdlkfjs sfjksfklsfksj fsdfsd
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
like: Find problems quickly - Quick to test that my code is working (no compiler or runtime errors) - Assurance that I can reuse the test in the future when refactoring
like: Find problems quickly Love the incremental devlopment
like: Find problems quickly Love the incremental devlopment
like: Find problems quickly Programming errors are detected at an early stage.
like: Find problems quickly fast feedback
like: Find problems quickly Its easy to use.
like: Find problems quickly You see immediately when something breaks existing functionality
like: Find problems quickly Its power to prevent mistakes turning into bugs, sparing developer and testing team quite some time.
like: Find problems quickly Liked the approach as it allows to start testing at early stage.
like: Find problems quickly I like find bug when I change code
like: Find problems quickly I like find bug when I change code
like: Find problems quickly I like find bug when I change code
like: Find problems quickly I believe it will help find the problems early in the Life cycle of development than later.
like: Find problems quickly Small changes results in less time in the debugger - I can easily deduct what the problem is.
like: Find problems quickly TDD is good at catching errors very early.
like: Find problems quickly nice to work against something very specific, where the requierements are very clear. no guessing
like: Find problems quickly test 2
like: Find problems quickly verifiable progress
like: Find problems quickly Refactoring was easier to debug because of the previously built up tests.
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.
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.
like: Find problems quickly Mandates writing cleaner code in small units, with lesser chances of breaking something with new code.
like: Find problems quickly If you change something and it breaks a previous test, you know immediately.
like: Find problems quickly Made me slow down and think about the test and ways the code could fail before writing code.
like: Find problems quickly The feeling that you are always progressing
like: Find problems quickly Code design along with the test cases to find potential errors at the beginning
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.
like: Find problems quickly It's clear where the error was
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.
like: Find problems quickly I like that it increases my ability to Focus on one thing.
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.
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.
like: Find problems quickly When I broke the implementation, whilst adding a feature, the failing tests were really useful
like: Find problems quickly Small steps gives you constant feedback. It is easier to see where the problem is introduced.
like: Find problems quickly small changes makes it easier to find the problems (in theory)
like: Find problems quickly I like the idea of a feedback loop. Continuously getting feedback from the code as it's developed.
like: Find problems quickly It will help catch bugs early in the process. It also makes you think more before coding
like: Find problems quickly Easy to identify when new code breaks existing work.
like: Find problems quickly It letd me test the function that is just implemented, which helps to quickly find out issues if any.
like: Find problems quickly Seems good at catching errors.
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.
like: Find problems quickly Very fast feedback if my implementation works. The solution can be quickly found.
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!
like: Find problems quickly I like the fact that you can begin writing code without completely understanding how everything should function.
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.
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.
like: Find problems quickly Think before writing production code Catch unexpected edge cases
like: Find problems quickly I could find a sneaky bug from a previous implementation
like: Find problems quickly You can find bugs in code right away
like: Find problems quickly - Thinking about the use cases before designing the code - Breaking the functionality into small pieces eases the work.
like: Find problems quickly I like that it is a new way to approach thinking about code.
like: Find problems quickly Bugs and typos are revealed quickly (given that you implement the "right" tests)
like: Find problems quickly The test failures made locating source of errors easier than without TDD.
like: Find problems quickly The ability to catch a functional mistake that may have been an unanticipated side effect of some other fix.
like: Find problems quickly if you mess something up, you have instant feedback and you can instantly fix that
like: Find problems quickly It is esasy to implement. It is very intuitive. It seems to be powerful, because avoid to write some kind of non visible errors.
like: Find problems quickly found bugs fast
like: Find problems quickly Getting stuff working
like: Finding defect early Finding defect early.
like: FixFast I like the short time between failure through diagnosis to fix.
like: flow Good work flow (write tests first, build on-top of tests).
like: focus Helps frame the design by forcing to focus on one detail at a time.
like: forced perspective I enjoyed the minimal development approach. It forced me to adopt another perspective for debugging
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.
like: fulfilling Seeing progressive improvement was great. Able to execute my code without it being part of a larger component
like: Fun 1. Always fun to get your hands dirty!
like: Fun Less complicated than expected
like: Fun Allows for multiple refactoring without limits
like: Fun Its very fun
like: Fun We get to write code, that's small fun and easy
like: Fun I like the interface and the quips about getting too far ahead of ourselves. It really drives home the idea that we should atomize tests and iterate.
like: Fun I like the labs correlated to the training.
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
like: FUN I felt testing and debugging was fun. Before taking this class, I really didn't like debug my code.
like: Fun Practice to think by TDD when doing exercise.
like: Fun It is good experience to improve the code debug cycle time
like: Fun Very good experience. Was able to collaborate with part and trainer easily.
like: Fun Very nice collaborative experience.
like: Fun give an idea of how project can be broken out into modules and developing it in parallel.
like: Fun I like the fact that it enables you to have explicitly defined requirements and informs you when your implementation deviates from those. I also like the sharing of ideas between developers.
like: Fun I like the fact that it enables you to have explicitly defined requirements and informs you when your implementation deviates from those. I also like the sharing of ideas between developers.
like: Fun It was a pretty fun experience. Especially when I was working with my group.
like: Fun This exercise is very straightforward. There is a concrete process that we need to test and it challenges how we think about it.
like: Fun This exercise is very straightforward. There is a concrete process that we need to test and it challenges how we think about it.
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.
like: Fun The feeling of satisfaction when a test passes
like: Fun The feeling of satisfaction when a test passes
like: Fun Level seems well matched to pair programming: the discussion it stimulates is germane, and the right level of detail: neither trite nor overly in-depth and slow.
like: Fun Frequent rewards when individual tests pass makes it fun
like: Fun a like
like: Fun fun
like: Fun fun
like: Fun The exercise environment (cyber dojo) is really cool.
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.
like: Fun It is more interactive.
like: Fun The quick feedback makes it fun.
like: Fun after updating email
like: Fun When using TTD it gives you natural progression and structure in solving the problem.
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.
like: Fun Time is flying
like: Fun it is a very unique way of coding and thinking and i like it but it is a bit challenging one too
like: Fun I liked the Code Dojo concept - that made the setup and course stress FREE.
like: Fun It's more fun and less stressful.
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.
like: Fun James' light-hearted humour is a joy to follow ! Good thing you don't charge extra for liking more than one thing...
like: Fun It was fun to achieve small goals quickly!
like: Fun I like the idea of procrastinating - I think I can be very good at this
like: Fun the website
like: Fun It's fun to do "functional" code while the tests are being made. Then, when you add more and more tests, you need to change the implementation to fullfill all the requirements.
like: Function it seems to force you to really think about the function and responsibilities of parts of the code
like: future-proof It can prevent working portions of the code from breaking
like: Gamification It is satisfying to "solve" tests.
like: good a good test suite
like: good good overview enjoyed the practical so far
like: GOOD It is a good learning experience so far. It gives a good structural/procedural (test) approach to developing code while solving problems.
like: Good Approach I like the approach of the TDD training session
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
like: Great! I liked how methodical it is. Writing tests and watching them pass is fun. Making small changes is a great idea
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.
like: guidance TDD guides you to a clean interface and minimal implementation.
like: harness I liked the harness driven approach. It is faster than debugging.
like: Helps Helps you catch bugs early on
like: High test coverage It forces you to test every aspect of your code, potentially catching simple mistakes early in the development cycle.
like: High test coverage The process guyarantess high test coverage. Writing tests after you often end up not as thurough,
like: High test coverage It forces you to write testable code
like: High test coverage Sure not to develop unused code
like: High test coverage Trying out a different development style than what I am used to.
like: High test coverage I like that the tests are already written when the code is done.
like: High test coverage Good approach to have incremental regression tests for each and every small part of my software.
like: High test coverage I like the idea of having more complete testing coverage at the very beginning of implementation.
like: High test coverage I like the idea of having more complete testing coverage at the very beginning of implementation.
like: High test coverage I like how each test adds to the ways you're testing your code for each change. A test you wrote at the beginning can catch something much later when you've changed head space
like: High test coverage Starting to see how we should create the test cases first, then write the production code.
like: High test coverage I like getting to see how many valid tests can apply to even a simple piece of code.
like: High test coverage I liked the idea that there's a test for each feature
like: High test coverage The idea of writing only code that is testing, i.e. we would get 100% test coverage.
like: High test coverage it helps to see the way that the product will be used before starting to code it.
like: High test coverage When running a newer test, I have confidence that I did not break an early design element
like: High test coverage Forces you to think through and test the expected behavior at each step.
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.
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.
like: High test coverage Minimal setup needed. So, more focus on writing test cases
like: High test coverage - Unit tests are smaller and focused - Unit tests got more control flow/behavior coverage
like: High test coverage seeing the code getting build, just by passing the tests
like: High test coverage I am starting to see the way that this could help build good test coverage on new code.
like: High test coverage Deep understanding of the behavior of the code. Nothing escapes the testing, so it wont just work in the one tested case.
like: High test coverage Good test coverage
like: High test coverage I like that there is always a test for each piece of production code.
like: High test coverage Thoroughly written tests eliminate bugs. Requirements can be translated into tests - a test for each requirement or sub-requirement if they can be broken down.
like: High test coverage I like being told what parts of my code are not covered by tests
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'.
like: High test coverage I like that you build a bank of ever progressive tests which keep your code continually honest.
like: High test coverage High test coverage
like: High test coverage High test coverage
like: High test coverage Writing tests first improves test coverage. Fewer chances to not test for functionality that can happen if we write all the test at the end of development.
like: High test coverage See the deviance directly
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).
like: High test coverage It turns my world upside down.
like: High test coverage something from james
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.
like: High test coverage You are building your tests as you develop rather than doing it after the fact.
like: High test coverage As a student, I dreaded the fact that we have to test the code that we develop. Wasn't developing enough? Well, it wasn't. I came across TDD and many of my peers recommended to learn TDD.
like: High test coverage I have some prior TDD experience, but I never understood the point of writing tests first. I like the fact it helps with covering more edge cases.
like: High test coverage Test coverage is good.
like: High test coverage I like testing as part of the development process.
like: High test coverage Good exercise on function/test splitting
like: High test coverage fast feedback
like: High test coverage Good test coverage from the start, the debug loop is very tight.
like: High test coverage It forces you to test every line of code.
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
like: High test coverage Completion and actuation of high level features before low level realization. Usable regression record that builds during development
like: High test coverage I like the idea of consistently testing code during development.
like: High test coverage I like the idea of consistently testing code during development.
like: High test coverage I like the idea of consistently testing code during development.
like: High test coverage I like the idea of consistently testing code during development.
like: High test coverage It's organized and thorough
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.
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.
like: High test coverage Thoroughly testing individual functionality.
like: High test coverage It seems it allows us to test our applications as thoroughly as we developers need it to
like: High test coverage It make you think of all the different test cases.
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.
like: High test coverage I like that it helps in covering all paths
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.
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.
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.
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.
like: High test coverage Increased test coverage.
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
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
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
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
like: High test coverage Existing tests catch when new code breaks old functionality
like: High test coverage Good test coverage on the implementation.
like: High test coverage kjhakj akjalkjakjakj dkfjsdfjksd
like: Immediacy The short time between writing something wrong (even in so trivial an example as a circular buffer) and finding the mistake.
like: immediatly check error case & handle it immediately.
like: in progressive I liked that I can make the code in progressive from zero to hero.
like: Incremental Incremental development so always testing and find bugs early
like: incremental It's methodical, with only small changes made with each cycle
like: incremental It breaks down the problem. Enforces incremental development. Ensure that new features do not break existing ones.
like: incremental small incremental progress in the right direction == good
like: incremental Made inclemently implementing features easier.
like: incremental Incremental progress.
like: incremently It allows to test and check if the test is correct. Then increment your test and do the process again and again.
like: increments Small increments are easier to manage
like: instant Instant feedback if code is working
like: Instant Feedback Instant feedback if code is broken.
like: Interesting TDD can help us develop/test software while developing. It can slow at start but wonderful when complete.
like: Interesting TDD is a good a approach to systematically solve a programming problem, as the bugs can be fixed on the go.
like: interesting It gave me an idea of how to write fewer bugs in my code.
like: interesting Its an interesting way to test software. Which is a new experience for me.
like: interesting it's an interesting and different approach for solving a problem.
like: Interfaces Forces you to specify out your interfaces early (pre- actually implementing them)
like: intriguing Gave me a new perspective on Software development.
like: iterativ fast feedback with small changes
like: iterative The iterative nature of TDD. For the most part, it allowed you to focus on smaller pieces of the code.
like: iterative Helps to ingrain iterative development into oneself.
like: iterative The iterative approach to tested when done
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
like: language Not a new language to learn, more or less
like: Learning Learning about CPPU Test and a different development methodology and how I can apply it to my development style.
like: lego Short iteration with short implementation. You get more understanding of the code that you write.
like: like Minimizing the number of changes between executions of the test which reduces the possible causes of the failures.
like: like incremental development. validate, test, necessity of a , need for variables in microscopic details. emphasis on code coverage
like: loop I liked that the environment allowed for quickly running tests and seeing results.
like: love Not really first impression, but TDD is a game-changer that makes code development easier, safer and more predictable.
like: makeing test code I like making test code. it's a effective experience.
like: Memory Reminds you where you are on a task if you get distracted
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).
like: methodical I like that the development process is very thorough, methodical, and structured.
like: methodical Very methodical. I liked slowly working through all the implementation details through specific tests.
like: methodical The ability to test along the way ... takes care of the unit testing
like: mindset change Fail early, fix quickly
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.
like: Minimal implementation Don't implement anything else than what is tested
like: Minimal implementation Small incremental changes to code
like: Minimal implementation this is an good tool to verify the written code.
like: Minimal implementation It was interesting, not having to figure out the entire data structure and interface first. Iterative.
like: Minimal implementation forces you to get to the minimum complexity to meet requirements (expressed by tests)
like: Minimal implementation Less load on the brain by tackling one small step at a time. Less mistake working with small steps
like: Minimal implementation TDD allows me to develop a working code that is minimal but has all the requested functionalities. It is cool since I always add non necessary features. TDD will help me reducing overthinking
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.
like: Minimal implementation I liked the fact that you write only the code you need
like: Minimal implementation Helps with coding only what is needed and not more than that.
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.
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.
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.
like: Minimal implementation Helps you break things down to the most basic functions.
like: Minimal implementation Kept things simple
like: Minimal implementation advice about not getting bogged down in analysis paralysis
like: Minimal implementation I liked TDD naturlally restricts design scope. Having to thing of everyting all at once is tiring.
like: Minimal implementation TDD prevents overthinking and entering rabbit holes
like: Minimal implementation TDD prevents overthinking and entering rabbit holes
like: Minimal implementation Dealing with a very focused code, and minimal change
like: Minimal implementation I liked moving forward in small chunks. Each step was very simple.
like: Minimal implementation So far, TDD makes me overthink less
like: Minimal implementation I like the iterative and incremental nature of TDD.
like: Minimal implementation You only implement enough to pass the tests.
like: Minimal implementation fast approach to goal
like: Minimal implementation fast approach to goal
like: Minimal implementation simple, small test functions, testing only part of my code
like: Minimal implementation I liked that that you are getting constant feedback from the tests, even though you may not have a complete implementation done. Makes it a lot easy to find mistakes along the way
like: Minimal implementation Not need to focus on the entire problem at once.
like: Minimal implementation Is this unit test macros available to use. easy to modify for our output needs?
like: Minimal implementation making small changes at a time
like: Minimal implementation It keeps the focus on exactly the feature that's being implemented
like: Minimal implementation Taking small steps
like: Minimal implementation TDD forces you to only implement what's required. Also what's implemented has tests.
like: Minimal implementation I like the approach of incremental development, bakes it easy to break up large tasks into simple problems.
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.
like: Minimal implementation Keeping it simple.
like: Minimal implementation No need to lose your thoughts in complex functions.
like: Minimal implementation No need to lose your thoughts in complex functions.
like: Minimal implementation No need to lose your thoughts in complex functions.
like: Minimal implementation Unnecessary code in production code is avoided
like: Minimal implementation TDD allowed me to overcome a great problem: creativity blocks.
like: Minimal implementation slice the problem into small steps => reduce the complexity
like: Minimal implementation Simple. Short easy goals for each function, adding scope over time.
like: Minimal implementation I like that the tests are fairly straightforward once you get the concept
like: Minimal implementation typically it's less work than expected per test
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.
like: Minimal implementation We moved in small steps and incrementally worked out an API. Nice use of ZOM...
like: Minimal implementation Breaking down a larger task into smaller more manageable tests.
like: Minimal implementation Breaking up a big issue into smaller segments
like: Minimal implementation Breaking up a big issue into smaller segments
like: Minimal implementation Breaking the problem down into small (initially insufficient) incremental steps.
like: Minimal implementation You are forced to think about the minimal needed logic for your implementation
like: Minimal implementation you can develop a test with less code and it is very fast giving a result
like: minimalist I like the idea of not building anything more than what you are currently testing.
like: mistakes Experiencing mistakes I do in coding, like wrong checking
like: modular The coding and logic manipulations. Forces modular implementation
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.
like: New Learning a new development approah, writing a test before writing the implementation.
like: None not sure if I like it.
like: not as much overhead The process did get easier as the implementation became more complete.
like: nothing nothing.
like: Other. I first need to think how I/someone would like to use the class
like: Other. Think "not happy path" from the start
like: Other. Think "not happy path" from the start
like: Other. I like that TDD helps build a defined behavior for your code.
like: Other. I like that I can run tests over and over fairly easily.
like: Other. breaking the problem down into very small testable increments
like: Other. I like the idea of test driven development but concerned that it may not be practical.
like: Other. You develop a test suite for your code as you write the code. This has immense value.
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
like: Other. Behavior is defined before code.
like: Other. Helps to find small bugs like typos right off the bat.
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.
like: Other. The Cyber-Dojo training platform is set up well for TDD training.
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.
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.
like: Other. easy to come back to after encountering distractions
like: Other. Fast feedback, feels more rewarding and make it easier to add new features which will definitely work properly.
like: Other. Balance more fairly the code dev and the test dev at the same moment in time of the flow. Model the code expectation prior to its development, thus express the exact needs.
like: Other. Seems to force breaking the task into bite-sized pieces.
like: Other. I liked how detailed the guidance was on the first exercise
like: Other. TDD is good at capturing requirements: you have a requirement, you write a test for it, then you implement the requirement
like: Other. this and that and the other
like: Other. I like that is makes you think about the purpose behind your code/function.
like: Other. this and that
like: Oversight TDD help prevent creating undetected bugs in existing code when making modifications or refactoring.
like: passes I liked making code to pass the test, even though the test was simple.
like: peace of mind Having confidence that my code is somewhat tested
like: Piecemeal Forces you to think in little (testable) pieces
like: positive feels like you can make significant progress without completing much functionality
like: Precision The idea of finding a way to codify your class' behaviour before you write it
like: presence TDD saves you from thinking about future problems too early.
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.
like: prioritize I like that it pushes writing tests to the forefront of your mind when programming, not just an afterthought.
like: Proactive Focus on testing upfront.
like: process Getting a demonstration of how it is applied from an expert. The pattern of fail compile, fail link, fail test, pass test.
like: Process It's a process
like: procrastination it is OK to be a 'lazy' programmer, and procrastinate until you are forced to.
like: Progress The instant feedback of progress.
like: progressive I liked that it was testing chronological building blocks. Building into larger more complete pieces of code.
like: Promising Better opportunity to validate expected behavior and move on, while also identifying and testing edge cases.
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
like: proof I can get each line of code tested.
like: Quality Quick feedback loop when implementing -> continuous improvement.
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.
like: quick Quick feedback
like: quick Quick feedback
like: Quick results Quick feedback when there is a but in the code.
like: Refactoring Easy refactoring. I know that things haven't been broken by a change.
like: refactoring Helps with refactoring.
like: regression Like that it creates way to check other changes that shouldn't change functionality and provides regression
like: regularity I like the regularity of the steps: do the same process, one bit at a time
like: reliable I like that you test as you go and so your code is more reliable.
like: requirements I like that you can map requirements to code more easily.
like: Rewarding It is rewarding to see the result immediately (not so rewarding when breaking a test ;-) )
like: robust You can refactor/add code with less worry about breaking existing functionality
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.
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.
like: safe code I got the feeling of building up the code.
like: safer Feels safer to change code
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.
like: Safety net I like the safety it produces in a continually evolving code base. Ensuring future changes don't break pre-existing code.
like: safety net easy to change without risk of breaking something
like: safety-net I like how the tests seem to "lock in" the behavior as you go along
like: Satisfaction TDD makes me feel some satisfaction and progress.
like: self-regulating It makes the programming process rigorous and self-regulating. This prevent bugs from compounding and developing into massive bugs.
like: Sensible The concept of driving development by testing makes a lot of sense. I'll definitely be using this approach in the future.
like: separated Complex implementations can be simply separated.
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
like: short failures That there are only short intervals of being in a state of not-working.
like: show I like having the tests to show me what's not working.
like: simple Clear, simple framework
like: simple it dosent take a lot of effort to make your code pass
like: simple I liked the incremental approach.
like: simple Can concentrate on very small functionality at a time.
like: simplicity I like the iterative develop to get the smallest solution working.
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.
like: Simplicity 1 Thing at a time
like: Simplicity forced to focus on one thing at a time
like: small I like that it forces you to implement the code step by step, with small increments.
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.
like: small step software problem are divided is many smaller problem that are more easier to fix.
like: small steps its breaking up development into small steps
like: small steps Like that it forces small steps
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.
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.
like: Stable If test code gets well made, it looks we can make really stable S/W at the first time.
like: step by step I can develop step by step more logically.
like: straightforward It is a more straightforward/mechanic method to develop
like: Strong Very simple. Easy for understand
like: Structure Enforces you to not add unnecessary code -> adds structure to the process of implementation.
like: structured It's structured, that helps to detect errors earlier.
like: structured It forces you to create the API functions early in the process
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.
like: Structured approach The incremental approach to solving the problem will clearly make more complex work easier to develop. I also like the built in validation of functionality for the future.
like: Structured approach step by step which is more interesting, instructing and inspiring
like: Structured approach I like the "keep it simple stupid" approach. I feel I would help me get some work done even on an day when I'm slightly off my game.
like: Structured approach Following this discipline you have better chance of having working code and good test coverage and the possibility to find problems faster
like: Structured approach It is disciplined way of development that allow developers to think about each step and how changes can impact each other.
like: Structured approach Things should be done step by step.
like: Structured approach Thinking about the corner-cases before doing the implementation helps you reach a better implementation
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.
like: Structured approach I like the simplicity, the structured way of implementing the code.
like: Structured approach Good presentation Nice to have exercises and quick feedback Structured way of coding
like: Structured approach I liked the systematic approach to ensure a safe code
like: Structured approach It was interesting
like: Structured approach Easy to run tests with Cpputest framework
like: Structured approach Kinda forces a more structured way of coding.
like: Structured approach How I need to wait and realise what I need to test without adding extra functionality.
like: Structured approach I like the test of the test approach
like: Structured approach Forces you to think about all the edge conditions.
like: Structured approach Offers a structured method to developing software.
like: Structured approach Let you build tests that you were confident in even if the implementation underneath was only half-cooked
like: Structured approach Code driven by interface
like: Structured approach it makes clearer the requirements.
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.
like: Structured approach It makes easier defining better signature (good for sharing)
like: Structured approach The constant reminding of precise definition of what the functionality is supposed to do.
like: Structured approach I need to think about few things at one given moment
like: Structured approach Clear method
like: Structured approach TDD makes development & unit testing well structured. It makes easy to see what's tested and what's not.
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.
like: Structured approach Iterative and incremental with tests baked in feels good. Don't need to race too ahead of time.
like: Structured approach I like how TDD defines a process to validate the tests themselves as well as the code under test.
like: Structured approach iterative testing
like: Structured approach I liked pair programming, breaking the problem up into manageable parts
like: Structured approach I like the baby step approach to developing code.
like: Structured approach It requires you to state and describe the behavior you want.
like: Structured approach It forces you to analyze and implement concise member functions while testing/validating the input to those function.
like: Structured approach the TDD method is very interesting and the step to add code step by step according test case
like: Structured approach i liked the idea of minimal incremental implementation, but also having a solid test base of main functionalities of our software module, that can catch regressions when extending the implementation
like: Structured approach I liked how this enables us to build step by step to arrive at a final solution.
like: Structured approach Since I'm new to C++ (former C user), it was nice to both dabble in C++ and learn TDD at the same time.
like: Structured approach It Breaks down a task into small manageable chunks that make it easier to complete a difficult task. It Breaks down a task into small manageable chunks that make it easier to complete a difficult task
like: Structured approach I like the way the course steps you though each new Test.
like: Structured approach I like the way the course steps you though each new Test.
like: Structured approach That is forces you to slow down and think through next steps.
like: Structured approach readability of testing intent
like: Structured approach Have to define what a function is going to do before any code is written, which helps with the programming process.
like: Structured approach I like how TDD walks you through the process of developing and makes it easier to plan out your code.
like: Structured approach I do like the structure created a lot, it helps reduce analysis paralysis and scattershot coding
like: Structured approach Easy to understand, step by step behavior. Let me focus on 1 feature at a time
like: Structured approach Have a specific outcome in mind for your functionality and keeps you on track to not deviate and have scope creep.
like: Structured approach Logically and iteratively working through a problem to get to a solid solution.
like: Structured approach Though it would take getting used too, I like the consistency of the process.
like: Structured approach very enjoyable -- could be very useful in overall software architecture planning phase; feedback, constant progress through well thought out process.
like: Structured approach This approach does layout the skeletal structure in terms of the requirements, assuming at least one test per requirement.
like: Structured approach For this first exercise, I liked going step by step and making us think about how we would write the test and what source the source code needed to look like to make the test pass.
like: Structured approach I like how structured it is and forces you to think about one thing at a time. But it will take some time getting used to.
like: Structured approach I like the exercise - simple and easy to understand the principles.
like: Structured approach i like how my code was getting incrementally more and more complete
like: Structured approach It allows me to write the code organically through tests.
like: Structured approach The build & run environment being all set up. It's a nightmare getting many students set up individually.
like: Structured approach Methodical
like: Structured approach TDD makes you step away from the nitty gritty details and instead focus on the intended functionality of your API.
like: Structured approach Frameworks are good
like: Structured approach We are adding one thing at a time and testing at fine granularity
like: Structured approach Early feedback and confidence that code is tested alongside development
like: Structured approach I like how sequential it is and how it leads you through a prescribed process.
like: Structured approach I appreciate the self-directed flow using comments as a "discussion" and the #def as a stop point.
like: Structured approach Starting point is relatively simple
like: Structured approach I liked that the exercises are small and manageable and drive the point home.
like: Structured approach I like the hands on experience. Putting theory into practice helps reinforce the concepts
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.
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.
like: Structured approach The step-by-step approach. so that we don't skip or jump minor details
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.
like: Structured approach It's methodical and a consistent process
like: Structured approach It is satisfying that once the code has been finished, the testing is too!
like: Structured approach Eliminates analysis paralysis and provides clear path of what to do next in small digestible pieces.
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
like: Structured approach The address one "problem" at a time approach
like: Structured approach I feels like a very systematic way of working.
like: Structured approach Very structured, iterative approach to implementation. Tests so far have been very explicit (not testing too much at the same time).
like: Structured approach Being able to track the pass -> fail of every test, ie incremental development
like: Structured approach step by step thinking makes it easier to cover all the test cases, it also makes my code work better (less debugging) when there is more planning.
like: Structured approach i liked going step by step through the tests. i dont do it like that in my day to day work and it was therefore a new perspective getting into TDD, since we "had" to do it :)
like: Structured approach structured way of working
like: Structured approach Incremental development mind-set
like: Structured approach Fast feedback
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.
like: Structured approach I like the iterative approach in building functionality as I develop a similar way
like: Structured approach Definitely liked working with a partner, helps things move faster.
like: Structured approach I liked the exposure to creating test environments for a particular problem. The practice was very nice to have.
like: Structured approach Adds a structure to the development. Feature by Feature rather then a jumble of code not working until the end.
like: Structured approach I enjoyed how TTD made the code creation more structured
like: Structured approach It makes you consider things step by step which helps to really consider the problem
like: Structured approach I liked being able to methodically move from a requirement to a test (at least for this simple exercise)
like: Structured approach How we solved one problem at a time
like: Structured approach I liked the fact that the approach is a simple step by step to your eventual desired behavior.
like: Structured approach I liked the exercises that were given to us and working with my co-workers helped enhance my experience. I felt like I did something while participating in the session.
like: Structured approach I like how the TDD helps with building the code piece by piece so it makes the debugging easier and know where the problem is.
like: Structured approach The structured approach was very helpful in writing function implementations and testing code side by side.
like: Structured approach I like that the code will have well defined requirements and should have tests implemented already
like: Structured approach The code came together well at the end and you know it's decent code because it was tested
like: Structured approach Very methodical and thought process is traceable assuming we use version control for intermediate checkins.
like: Structured approach Makes you solve a problem in small, logical steps as well as generating the tests as you go
like: Structured approach The incremental nature of development. It matches how a structured mind approaches a problem.
like: Structured approach The incremental nature of development. It matches how a structured mind approaches a problem.
like: Structured approach The incremental nature of development. It matches how a structured mind approaches a problem.
like: Structured approach The tests define the functionality of the code which makes it simple to understand how it is meant to work
like: Structured approach Fast pace. Clear simple rhythm.
like: Structured approach Fixing failures sequentially to pass the defined tests, feels like constructive
like: Structured approach It addresses the problems in incremental steps so you dont get bogged down its ok to make mistakes because the tests will pick them up
like: Structured approach Get to think through expected behaviour/implementation more. Tests protect against future bugs. Not implementing more than you needed to
like: Structured approach It did help build up a systematic test suite.
like: Structured approach "Iterative" working code, solving small puzzles at a time and building block.
like: Structured approach I like the structure coding approach TDD forces you to do so
like: Structured approach Do not really know yet...
like: Structured approach The structure makes sure I am less likely to forget steps/things
like: Structured approach It seems to be a good way to cut a problem into "small pieces".
like: Structured approach We have a very structured structure
like: Structured approach Solve one problem after the other.
like: Structured approach It made workflow how TDD should be done very clear
like: Structured approach Interesting new approach, you need a new way of thinking
like: Structured approach It makes you actually think about the outcome in advance, but step by step.
like: Structured approach you work step by step; but it is a little bit "strange thinking" (its new)
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
like: Structured approach To have a concrete example on how to use TDD and practice it
like: Structured approach To have a concrete example on how to use TDD and practice it
like: Structured approach I like out tests build on each other to keep your code honest.
like: Structured approach It's systematic in its approach.
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.
like: Structured approach I liked the formulaic approach to development. It helped me to not bite off more than I can chew while making steady progress.
like: Structured approach I am forced to divide my problem in small steps, which build on each other. This leads to an better understanding of the code.
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
like: Structured approach I liked having (N) functionality confirmed before adding (N+1) functionality. It makes sense.
like: Structured approach The cyclic framework (compiler fail, linker fail, test fail...) is simple and effective. Code written this way I feel is going to be robust, it has passed a minimum quality standard.
like: Structured approach Good strategy to stepwise implement functionality
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.
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.
like: Structured approach With incremental coding comes very many successes! :)
like: Structured approach I like the structure, such that progress is concrete.
like: Structured approach If done in concert with a separate but conjoined design activity, TDD ensures that design intent is met
like: Structured approach I liked that TDD forces you to examine the behavior before starting.
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.
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.
like: Structured approach It helps break the problem up into small steps and forces me to logically think through the code development.
like: Structured approach TDD makes you think about HOW the design works and how it can fail
like: Structured approach Very interessting, I definitely liked that the "API" is written before any code changes.
like: Structured approach TDD makes you think about the code incrementally, making it easier to design correctly.
like: Structured approach The way you think: making little increments from the simplest thing
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.
like: Structured approach there is a certain structure of doing TDD that helps coding faster/easier to do and manage.
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
like: Structured approach It's thorough.
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.
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.
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.
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.
like: Structured approach I could TRY to ignore the future problems bouncing around in my head.
like: Structured approach Test when passed, felt good. Liked how the small each of the steps were - seemed to break down the problem well.
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
like: Structured approach Testing guides your code development.
like: Structured approach Test code is clean.
like: Structured approach This is straightforward method
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.
like: Structured approach Makes you really stop to think about the requirements
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.
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
like: Structured approach TDD definitely provide a disciplined approach that looks like it's worth the effort.
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.
like: Structured approach That I have a structure for creating test cases.
like: Structured approach Once you get into the routine, it's very methodical and iterative.
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
like: Structured approach The TDD macros gave a nice baseline test environment.
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.
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.
like: Structured approach The production code is easier to read.
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.
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.
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
like: Structured approach the camaraderie of thinking together -- we paired in -- to systematically think through a problem.
like: Structured approach The step-by-step methodology allows complex code development over time, and I can see immediately why this is widely used.
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.
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.
like: Structured approach I liked that it made it easier to create the final product from scratch. There were clear cut goals to complete.
like: Structured approach It's a way for methodical progress and provides a safety net.
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.
like: Structured approach It was a good way to force me to break down the problem, and solve it in pieces.
like: Structured approach It forces you to deconstruct what you are trying to do.
like: Structured approach * Is a new design philosophy, that improves the development process and the system safety.
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.
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.
like: Structured approach Following a algorithmic method for implementation is helpful, especially at this early stage in my TDD understanding.
like: Structured approach Learning a more structured way of coding
like: Structured approach Simple to follow process.
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.
like: Structured approach I liked making the incremental tests pass and adding functionality as it was necessary.
like: Structured approach TDD is good and is allowing us to work in groups. Learning about the Unit testing is also good so far. The platform is pretty good as well.
like: Structured approach After implementing some features, you realize that bugs will show up in the following tests due to "bad implementation" of your solution.
like: Structured approach It is hard to frame test cases initially, but I believe it has a structured approach that eliminates many loopholes.
like: Structured approach Fast feedback while working on the code. Forces you to think about test and the interface/usecase while coding.
like: Structured approach jkassdlkjashdlkjasdlkajsdshlka asd askjhasdkjh
like: Structured approach Well-defined steps that test the tests as well as implementation.
like: Structured approach The work evolves straightforward. You just have to change your mind, and do not run.
like: Structured approach It's good so far. Very systematic approach (If I can get the hang of it :)). Bit different way of writing the code than my usual day to day coding practice. Basically, it's a different mindset.
like: Structured approach I liked the thought process that's involved in breaking the design/coding of a problem (a single function in this case) into small iterative steps that build up the functionality.
like: Structured approach I really like one test for behaviour - previously my tests were messy
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.
like: Systematic Methodical approach
like: Systematic A systematic approach
like: Task Creation Breaking down a large task into multiple smaller tasks
like: Test Coverage The test coverage you're left with once complete.
like: test first I was impressed about starting with test codes and then implementing.
like: test like develop Test also looks developing by making goot test code
like: Test while develop I liked the idea as it allows you to test while you are developing your module.
like: test-coverage TDD results in small, well-tested units of code. Good tests and code coverage happen naturally.
like: test...test forces you to test your implementation while you develop the interface for your code.
like: Testability Makes you think about development step by step and each part is proven with a new test.
like: tests Tests are present for functionality.
like: testthetests I like that it "tests the tests" by ensuring they can fail.
like: think Makes you stop and think about how your implementation will work before you actually implement it
like: think corner cases We can think about corner cases before writing code
like: this this and that
like: Thorough The emphasis on failing early and often.The incremental approach to building tests.
like: thorough We are coding while testing. Since we are coding only as much as we are able to test, test coverage is excellent.
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.
like: time saving saves time otherwise spent debugging
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
like: Traceable it is easier to trace where we went wrong in the code. and took less time to fix it.
like: tricking tests The exercise we performed demonstrated the importance of writing test sets that can't be tricked into passing.
like: unbiased Testing is considered upfront before any code is written.
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.
like: Understanding It brought attention to logic errors early on, and provides a better understanding of how/why sections of code work.
like: Unsure I don't know enough to know what I like about it just yet.
like: upfront It forces you to flush out your interface and requirements as you write code without leaving the testing to the end.
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.
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
like: Useful-test-platform Reduces future debugging efforts, able to catch the bugs early.
like: usefull It catches design problems and logical errors early before they become baked into the code
like: validation validation will drive the implementation, not the other way around
like: validation It is great seeing confirmation that the code you're writing is working as you're writing it.
like: warm fuzzies That your velocity increases as your body of written tests grows, and you get more warm fuzzies.
like: way to go helps to make code more robust
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"?
like: wonderfull I like the way to step by step implement a complex feature with test case for each step.
like: workflow The course will teach people how to perform unit test, integrated test, system test.
like: working The ability to keep code working.
like: Wow Should think about the system before start writing code. write and test continuously.
like: YAGNI Helps with YAGNI because I can't write code if it doesn't have a test