Wingman Software

What 1516 people liked about their first TDD experience

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