What surprised 517 people about their first TDD experience

Course code Kind In a Word Impressions
V**-1 surprise #compiles the amount of compilations/builds
V**-1 surprise #compiles the amount of compilations/builds
T***-1 surprise 851 surprise 851
Z**-1 surprise adaptable It was surprisingly easy to continue doing it, once I started
C**-1 surprise Almost automaticly writing tests. Almost automatically writing the tests
C**-1 surprise Almost automaticly writing tests. Almost automatically writing the tests
J***-1 surprise Almost automaticly writing tests. The interface is simpler that I imagined -- getting a testing environment set up is usually frustrating
R**-1 surprise Almost automaticly writing tests. With using TDD you nearly get the tests for free
R**-2 surprise Almost automaticly writing tests. More fun than expected!
S***-1 surprise Almost automaticly writing tests. Ease of use. How quickly new tests were built, new production capability added!
U**-1 surprise Almost automaticly writing tests. Easy to use and rapidly expandable test framework that helps in the actual implemenatation in an iterative way.
W**-22 surprise Almost automaticly writing tests. Once you get the flow of the process it clicks and to development process flows quickly
W**-22 surprise Almost automaticly writing tests. The main thing that surprised me about TDD is the fact that in this approach testing guides the development. That is, the test cases have to be developed such that the source code is well covered
W**-23 surprise Almost automaticly writing tests. That making a known insufficient implementation actually reveals that the tests are not yet good enough
W**-25 surprise Almost automaticly writing tests. I can write unit test and think like a end user
W**-25 surprise Almost automaticly writing tests. we have tests now
W**-32 surprise Almost automaticly writing tests. How it helps to keep the implementation simple and composable.
W**-34 surprise Almost automaticly writing tests. This course made TDD in C easy. It was quite difficult before for me even though I have previous experience with TDD in C like languages.
W**-35 surprise Almost automaticly writing tests. Upon completion of development you also have completed test cases, no need to assign hours to someone to write tests
W**-35 surprise Almost automaticly writing tests. Tests are written quite fast.
W**-35 surprise Almost automaticly writing tests. The small test steps and it is helpful to cover all the edge cases.
W**-36 surprise Almost automaticly writing tests. Force you to write clean code as you go in order to be testable. It's so satisfying to get immediate feedback. Not obvious for everyone!
V****-2 surprise Amazing I used to think Unit-testing as more of process to complete development work but going through TDD, it looks like unit testing is fun too.
Z**-1 surprise automatic It surprised me how TDD helps write tests in sort of an "automatic" way.
C**-1 surprise Awareness I feel it creates a kind of awareness to your own mistakes and hence there are lesser chances of going wrong, if not completely correct.
C**-1 surprise bits it might be easier to build up little bits of correct code than to try and develop all of the functionality initially
C*****-2 surprise boring how boring it was
B**-1 surprise Bug-resist It definitely has potential to do great in catching bugs early
T**-1 surprise bugs How many unexpected bugs I write.
W**-21 surprise build aspect It feels very fluid. We are not overwhelmed with whole picture, instead we are building the picture as we go, piece by piece.
W**-18 surprise catharsis TDD is very cathartic, You feel confidence in your design as you go.
W**-21 surprise challenge There can be multiple test cases for small code we write.
B***-1 surprise Challenging The difficulty I had in keeping to the smallest change possible that makes the code work.
B***-1 surprise clear clear concepts, easy to use.
A**-1 surprise Code is incomplete for so long. You modified your test as long as you are developing the code, you procrastinate a lot more than I expected
A*-1 surprise Code is incomplete for so long. The small increments are very very small in some cases.
A*-2 surprise Code is incomplete for so long. The amount of tests is larger than when I do TDD myself, I take larger steps, more checks in one test and I _know_ how it should be implemented. I'd immediately step on toward dynamic allocation.
A*-2 surprise Code is incomplete for so long. Implementing things wrong
B***-13 surprise Code is incomplete for so long. Code is incomplete for so long it makes me want to jump ahead!
C****-25 surprise Code is incomplete for so long. the reverse approach compared to the usual one
C****-25 surprise Code is incomplete for so long. Clean implementation step by step and easy refactoring
C****-25 surprise Code is incomplete for so long. code might not get complete if test suite is not complete
C****-25 surprise Code is incomplete for so long. How much "faking" it involves initially.
C**-1 surprise Code is incomplete for so long. you can have a lot of green passing test but code is incomplete.
E*-1 surprise Code is incomplete for so long. So much more time is spent writing tests than the logical code.
E*-1 surprise Code is incomplete for so long. The most challenging part was not getting ahead of the tests when writing the code for the functionality itself.
J***-1 surprise Code is incomplete for so long. It's surprising how long the code can be "test-correct" but not actually "requirements-correct". The eventual converging is nice to see.
J***-1 surprise Code is incomplete for so long. I didn't realize that I'd start off with more tests than design in TDD.
J***-1 surprise Code is incomplete for so long. The code for the first few tests are sparse
N***-1 surprise Code is incomplete for so long. It seems like the tests are more important than the code, since at each step we only strive to make the next test pass, nothing more.
N***-1 surprise Code is incomplete for so long. Takes a long time to get to code that's doing what it's supposed to
N***-1 surprise Code is incomplete for so long. Hard-coding pushes implementation out
N***-1 surprise Code is incomplete for so long. Procrastination is good :P
R**-1 surprise Code is incomplete for so long. in larger components/classes, tiny steps like this are feeling clumsy..
R**-1 surprise Code is incomplete for so long. We are starting by "dummy code", that turns into final implementation when we have exhaustive tests.
R**-2 surprise Code is incomplete for so long. I rally did not know that it for TDD I need to write the code skeleton first... but this is fun.
S***-1 surprise Code is incomplete for so long. I'm surprised only implementing the bare functionality of the tests created a usable CircularBuffer, I'm suspicious if that same approach works on more complex designs though.
T*-1 surprise Code is incomplete for so long. too small steps to achieve a running functionality
U**-1 surprise Code is incomplete for so long. Weak design probably until you have covered all the scenarios.
W**-28 surprise Code is incomplete for so long. Writing code that is incomplete is OK.
W**-28 surprise Code is incomplete for so long. the feedback is nice. would need more practice to say more
W**-28 surprise Code is incomplete for so long. How hard it was to force myself not to implement more code than what was needed to pass the tests.
W**-29 surprise Code is incomplete for so long. The step-wise fashion of fail/pass.
W**-31 surprise Code is incomplete for so long. Difficult to go "one step at a time".
W**-32 surprise Code is incomplete for so long. How long it takes to get a working product
W**-32 surprise Code is incomplete for so long. Found I needed to hold myself back from jumping ahead to a full featured design.
W**-33 surprise Code is incomplete for so long. We first write code that is "wrong" but passes tests, but will be corrected later when writing additional tests.
W**-34 surprise Code is incomplete for so long. You make code not completly fonctionnal and you test it.
W**-34 surprise Code is incomplete for so long. Faking out results in the beginning as opposed to implementing minimal functionality.
W**-35 surprise Code is incomplete for so long. I'm finding problems I would've overlooked, although this is really a function of how complete the tests are.
F**-1 surprise coding direction At first of the previous exercise, we just tried to implement "cheat code" to pass the test cases. However, went to some last test cases, we need to write the code in the right way.
W**-21 surprise Confidence This helps to capture bugs earlier during the development itself. The measure of confidence I get when I write tests is amazing.
C*****-2 surprise confusion I read about writing the tests to just pass regardless of whether functionality is what you want in your book, but I was surprised at how much actually trying to do it that way confused me.
L*-4 surprise Considering_REQ It makes me think deeply about the requirement/design before the implementation.
C**-1 surprise convenient A complex problem is broken down in manageable pieces.
B***-2 surprise CppUtest Rox! CppUtest continues to be awesome around memory corruption and leaks!
B***-1 surprise design You can design the coding and testing then implement them
L*-4 surprise developement Feels like developement, not test
V**-1 surprise development support Some solutions in the algorithm was already implemented by implementing and solving a smaller part of the problem.
D****-2 surprise difficulty Everyone seemed to struggle a bit, even ppl who've had experience w/testing.
B***-2 surprise disruptive How different it is, when you're actually doing it, from almost anything I have been taught.
B***-1 surprise document A uniform way to build and document test cases.
M***-1 surprise ease/speed Once the API exists (more or less as it is not yet complete in the beginning), writing the tests feels simple and relatively fast. Probably because we are already familiar with FIFO solutions.
A**-1 surprise Easier than I thought it would be. The ease of use of the tools.
A*-1 surprise Easier than I thought it would be. Automatic detection of memory leaks.
B***-13 surprise Easier than I thought it would be. Is surprisiling effective given the amount of test code one needs to write.
B***-13 surprise Easier than I thought it would be. It felt more iterative and less tedious than I expected.
E*-1 surprise Easier than I thought it would be. How quick it can be once initial setup is done.
N**-2 surprise Easier than I thought it would be. The few cases where the test already passed, I didn't need write anything additional
T*-1 surprise Easier than I thought it would be. easy to use
U**-1 surprise Easier than I thought it would be. It is fun
W**-24 surprise Easier than I thought it would be. At the end of the day, I don't feel like it really added that much time given how much time would normally be spent debugging to get things working.
W**-26 surprise Easier than I thought it would be. Surprised how easy it was to setup.
W**-29 surprise Easier than I thought it would be. It's easier than I expected.
W**-32 surprise Easier than I thought it would be. you can start even before production code is written
W**-34 surprise Easier than I thought it would be. Implementing the test in the code is easier than I expected.
W**-34 surprise Easier than I thought it would be. I did not knew TDD in C was possible.
L*-4 surprise easiness It's easier than I thought. It can be automatic.
C**-1 surprise easy Had no expectations, but it has been easier to follow than what I anticipated
L*-4 surprise Easy Easy to make TEST code
L*-4 surprise Easy Easy Concepts and Applications
T**-1 surprise easy Easy to understand the concept.
V**-1 surprise easy easy to build/test from the get go. Perhaps not very surprising after all but anyways :D
B**-1 surprise easy prevence How it is easy to prevent silly and hidden bugs.
W**-21 surprise Easy to maintain TDD forces you to write unit tests before writing implementation code, refactoring of code becomes easier and faster.
M***-1 surprise easy to use Not as difficult as expected.
W**-21 surprise effective, confident Surprised about effectiveness of such methodology. Surprised that I can be confident for developed code, as I already tested most of it
W**-21 surprise Efficiency Easy Approach to test the functions
B***-11 surprise emergent the way a working and complete code-base appears out of thin-air
B**-1 surprise failure That we are supposed to make it fail first
W**-20 surprise failures Causing initial cases to fail.
C**-1 surprise fake it is OK to 'fake it 'till you make it'
W**-20 surprise fake it It is different than I thought from the start. I need to fake it until I make it and not start with a finished implementation.
W**-21 surprise Familiarity TDD in C++ isn't that different from doing it with other languages.
W**-18 surprise fascinating Time consuming
B***-2 surprise Flexibility The CppUTest infrastructure seems a good mix of formality and flexibility.
L*-4 surprise flow of coding The flow of coding with TDD seems reasonable.
B***-11 surprise force-fail Forcing failures as an effective technique.
D****-2 surprise foreign I was surprised by how foreign it felt, meaning how far I am from actually practicing TDD on a day-to-day basis.
W**-19 surprise free How easy it was to change the implementation/requirements while keeping confidence that the code will work. Testing was free at that point.
B***-12 surprise Fun More enjoyable than I thought
B***-1 surprise fun I found it a lot more fun than what I expected.
V**-1 surprise fun it did make writing code more interactive since we saw the result almost immediately
B***-12 surprise gamification how it started to feel like a game with the dopamine rush every time tests passed (and frustration when they didn't but I thought they would)
L*-4 surprise Good Code I surprised TDD could produce good code because it makes me think how to prevent bugs much.
F**-1 surprise Good to learn Have to think all possible test cases for a system.
F**-1 surprise great Testing API very well and clarify factors for these APIs
L*-4 surprise handy It's easy and handy
V**-1 surprise Hard How hard it is to stop yourself from not adding more functionality than needed. Easy to go too far too early
V**-1 surprise Hard A bit surprised how hard it is to NOT add more code than needed.
W**-20 surprise hard-coding It feels weird hard coding obviously incorrect code. How do you make sure that none of the hard coded things linger?
V****-2 surprise healthy TDD is a healthy practice as the developer need not concentrate much while developing software
F**-1 surprise helpful - Help developer think a lot about what they will code - Saving debug time
F**-1 surprise Helps development TDD actually helps a lot with the thinking during development
M***-1 surprise I can do this Step by step breaking bigger things up into smaller chunks
A**-1 surprise I spent less time thinking of implementation. Infinite tests
A**-1 surprise I spent less time thinking of implementation. No designing is required.
B***-13 surprise I spent less time thinking of implementation. It's interesting that it closely mirrors the oft-used blinking LED output that embedded engineers start with on new dev boards.
C****-25 surprise I spent less time thinking of implementation. Helps into designing the implementation.
C****-25 surprise I spent less time thinking of implementation. I spent less time thinking of implementation
C**-1 surprise I spent less time thinking of implementation. Not worrying about corner cases early on in the implementation, the test will guide me through to deal with the corner cases
J***-1 surprise I spent less time thinking of implementation. Thinking of the test drove implementation details at that particular snapshot. This eliminates my issue of overthinking and overdesigning implementations. Maybe I'll overdesign tests.
N***-1 surprise I spent less time thinking of implementation. It seems tests are too granular, however I can converge on working solution rather quickly.
N***-1 surprise I spent less time thinking of implementation. Having the set of test predefined made the implementation of the code much quicker
N***-1 surprise I spent less time thinking of implementation. I didn't have to think much about implementation before coding because you gave us the test cases
N***-1 surprise I spent less time thinking of implementation. Eases design decision, but again concerned about coming up with tests.
N**-2 surprise I spent less time thinking of implementation. I wasn't prepared to build code for the base code, I was only planning to add TDD code
N**-2 surprise I spent less time thinking of implementation. Not thinking ahead is harder than I thought.
R**-3 surprise I spent less time thinking of implementation. After struggling in the beginning it seems to be working very well. After setting up the base tests, its quite easy to write advanced tests
R**-3 surprise I spent less time thinking of implementation. If it works don't touch it unless a test fails :)
S***-1 surprise I spent less time thinking of implementation. I was actually able to solve the whole problem by only thinking about one thing at a time.
S***-1 surprise I spent less time thinking of implementation. TDD force me to think about the implementation of writing a buffer versus just hacking away at a fast implementation to get something to work without testing
S***-1 surprise I spent less time thinking of implementation. Implementing one thing at a time made the process of breaking the problem down automatic and methodical
T*-1 surprise I spent less time thinking of implementation. complete different way to develop software, but I like it
U**-1 surprise I spent less time thinking of implementation. How easy it is to build a working solution with making simple problems (tests).
U**-1 surprise I spent less time thinking of implementation. Change the way of developing code
U**-1 surprise I spent less time thinking of implementation. Time spent
U**-1 surprise I spent less time thinking of implementation. catching bugs, easy implementation
W**-24 surprise I spent less time thinking of implementation. The design decisions seemed to almost "fall out" of the tests.
W**-24 surprise I spent less time thinking of implementation. Having the tests to backup implementation and change make me more confident in my code, because I have proof that it works (at least as I intended it to works).
W**-26 surprise I spent less time thinking of implementation. Thinking about the test first made the code easier to implement.
W**-27 surprise I spent less time thinking of implementation. easier than expected to come up with tests.
W**-30 surprise I spent less time thinking of implementation. Given a well defined series of tests, implementation seemed lighter as a task.
W**-30 surprise I spent less time thinking of implementation. Although not really TDD its quite easy to implement the circular buffer when you have tests in place
W**-31 surprise I spent less time thinking of implementation. Having tests gives you more confidence in making changes.
W**-31 surprise I spent less time thinking of implementation. The interface and implementation seemed to emerge somewhat naturally from the requirements.
W**-32 surprise I spent less time thinking of implementation. Really surprised how I just started implementing the circular buffer without having to solve all of the steps in my mind first. Usually I have near full solution in mind before laying down code. Neat!
W**-32 surprise I spent less time thinking of implementation. Seems to lend itself to cases when the requirements are not well thought-out. Build the requirement into the test, implement to satisfy all tests. Don't over-engineer.
W**-35 surprise I spent less time thinking of implementation. Because of the small steps, there is less need to think about the implementation of the module.
W**-35 surprise I spent less time thinking of implementation. I was surprised how I never felt that the complexity is too high for the current task.
W**-35 surprise I spent less time thinking of implementation. no fear! gives a relaxed systematic approach
Z**-1 surprise impl-less I spent a lot less time thinking about implementation.
F**-1 surprise Improvement This course will help developers avoid bugs.
C**-1 surprise incompatible The fact that it seems antagonistic to requirements driven development, were you to follow it to book, you supposed to "discover" the requirements as you progress through the TDD cycle
B***-12 surprise incremental more and more completely considered
C**-1 surprise Incremental Encourages incremental development with fully tested code at each stage (albeit proof that the implementation is what you intended even if it may be incorrect based on requirements)
Z**-1 surprise incremental Small incremental steps actually lead to final solution.
W**-18 surprise Inefficient That you write implemention code at times that isn't the true implemention.
V****-2 surprise insight It provides a good insight into the process of coding
B***-2 surprise integrated Thought it was write test then write code, much more integrated
V****-2 surprise integrity write a code that shall work for ALL cases with intended behavior.
B**-1 surprise interesting interesting
W**-20 surprise iterative That decent, working code can be made iteratively, even though we started with horribly hacky code.
M***-1 surprise ItsNeverTooLateToLrn This is a very useful tool for development. I should have known much earlier :)
Z**-1 surprise lenient I was surprised at how much I was able to get away with a bad design until relatively far into the testing process.
C*****-2 surprise lies easier than you think to have bad code pass
B***-11 surprise Light? Getting up and running doesn't seem to require much in terms of "infrastructure" to support the framework.
D****-2 surprise like it I like it more than I thought I would
B***-1 surprise long-process how long it takes to do TDD
V**-1 surprise LowThreshold How easy it was to get started.
V**-1 surprise LowThreshold How easy it was to get started.
L*-4 surprise managed testcase Get systematically managed testcase
B**-1 surprise many steps There are a lot of steps to make sure that the tests are going to work the right way. Sometimes it is easy to get carried away with writing the code and forgetting to test.
L*-4 surprise many test case success many test cases more as I expect.
L*-4 surprise meaningful It really makes the codes meaningful.
B***-11 surprise microsteps Writing only as much code as is actually required to pass the tests.
B***-11 surprise Minimalist The benefits of TDD on the implementation of the code. The process of TDD generated a more minimalistic approach to solving a similar problem than writing the code first.
C**-1 surprise mistakes That I write the code as well as the tests.
C**-1 surprise nice It's pretty straight forward.
L*-4 surprise No bugs In well made test case, i just follow NG of test case result, and fix it. Finally, S/W gets done with no bugs automatically.
C**-1 surprise no surprises There is no suprise really. Its known but the value is realised when everbody practises it diligently.
T**-1 surprise none none
W**-19 surprise None No real surprises yet.
W**-21 surprise None None but I've been doing TDD for 10 years now.
A**-1 surprise None. You modified your test as long as you are developing the code, you procrastinate a lot more than I expected
A*-1 surprise None. Easy to get started.. (?)
A*-2 surprise None. Small dynamic development steps, allows for simplistic thought on design
B***-13 surprise None. I am surprised that aside from learning the new tools the TTD implementation is straightforward.
C**-1 surprise None. To be able to detect the code that does not have test coverage and not needed in that context. Add production code only when there is corresponding test failing and then it passes.
E*-1 surprise None. code will be fully tested
J***-1 surprise None. It seems to be a very thorough way of making your code robust
M**-1 surprise None. test surprise
N***-1 surprise None. There is a test framework. I don't always use a test framework but often end up building one for that code.
N**-2 surprise None. surprised how much more time I spent writing tests vs writing code. Much more time in the tests.
N**-2 surprise None. I haven't done c for quite a long time.
N**-2 surprise None. It's kind of fun after you get in the groove.
R**-1 surprise None. TDD is nothing new to me.
R**-2 surprise None. let tests fail first
R**-2 surprise None. Surprising is the concequence with which the method is done by you.
R**-2 surprise None. Now we are only taking about unit tests. What about integration tests of our modules?
R**-2 surprise None. I like the quality
R**-3 surprise None. Bugs are found fast.
T*-1 surprise None. Certain success with dummy code
T*-1 surprise None. Certain success with dummy code
W**-22 surprise None. hard coding at first, then change it when the test fails
W**-23 surprise None. How much fun it is!
W**-24 surprise None. interesting interactive approach both code testing and through online learning experience
W**-28 surprise None. At first my mind will lead me to start writing complete structure/ functions instead of following test. Even the test is there.
W**-30 surprise None. i am suprised that how will it be time saving ?
W**-34 surprise None. I make quite a bit of mistakes :)
W**-36 surprise None. I am surprised that TDD is not widely applied and used on a day to day basis. I was introduced to this method just in recent. It could be a course in universities. I would like to know the reason why.
B**-1 surprise not at all I already use it.
C**-1 surprise Not yet surprised I am not easily surprised :)
B***-1 surprise nothing Nothing.
B***-1 surprise nothing not sure
C*****-2 surprise nothing I've been doing this for personal side projects, so not a surprise.
V****-2 surprise Nothing Nothing
V**-1 surprise Nothing No surprise
A**-1 surprise Nothing. There is no surprise, is what I expect.
A*-1 surprise Nothing. I have not read or heard about TDD before so I didn't really have any expectations
B***-13 surprise Nothing. Nothing since I already practice is.
N**-2 surprise Nothing. I think many programmers may be doing tdd but do not realize.
R**-1 surprise Nothing. nothing
R**-1 surprise Nothing. Really!
S***-1 surprise Nothing. Its about what I expected.
T*-1 surprise Nothing. I follow normally TDD in my job. Sometimes logic used in first development needs complete change after TDD.
T*-2 surprise Nothing. It is as expected.
T*-2 surprise Nothing. Nothing
U**-1 surprise Nothing. Nothing
W**-24 surprise Nothing. Can't be surprised, very new to this type of flow
W**-25 surprise Nothing. It's about what I expected.
W**-28 surprise Nothing. So far nothing, but I have used it before
W**-28 surprise Nothing. Nothing so far :)
W**-31 surprise Nothing. Nothing
W**-33 surprise Nothing. None so far.
W**-34 surprise Nothing. I've been exposed to TDD before, so no real surprises
W**-34 surprise Nothing. No big surprises at this point
T**-1 surprise only what's needed Only focusing "on the next thing" ... only adding test functionality up to what you need now/next
B***-1 surprise oops How you can defer design and implementation.
A**-1 surprise Other. It is easy to understad, but I need to see that it really improves how I actually code (zero bugs).
A*-1 surprise Other. In my own playing with TDD, I have found that it sometimes catches flaws in the logic at an earlier stage than other methods. ( outside this course )
A*-2 surprise Other. Ability to find memory leaks
A*-2 surprise Other. How it helps to keep structured.
A*-2 surprise Other. Hard to keep train of thought. When switching between writing implementation and tests.
E*-1 surprise Other. learning a different methodology
R**-1 surprise Other. I made to many errors
R**-2 surprise Other. It takes even more time than I expected. So many intermediate steps have to be removed afterwards.
R**-2 surprise Other. too early to form an opinion
T*-1 surprise Other. no surprise yet
T*-2 surprise Other. is becomes like another code review - when it is hard to test then the code is weak.
T*-2 surprise Other. is becomes like another code review - when it is hard to test then the code is weak.
U**-1 surprise Other. How it is possible to be driven by testing. Targeting testing will lead you to the final solution, without realizing it.
W**-23 surprise Other. How much I was taking for granted with my existing approach to implementation
W**-24 surprise Other. Having to think about memory issues :)
W**-24 surprise Other. Surprised that I can still remember some C syntax.
W**-24 surprise Other. It was very easy to skip ahead and write untested code. Changing my mindset to be TDD would require more practice and discipline.
W**-26 surprise Other. this is my first CPP programming. but I can develop without stress. because compiler as guide syntax and easy to find What should I do next by small step.
W**-28 surprise Other. The first time I encountered TDD, the fact that not being able to compile was considered failing tests.
W**-28 surprise Other. How fast I can go because of my confidence.
W**-30 surprise Other. I was a little surprised that writing the tests would force me to think harder about the way the thing being tested was going to need to function.
W**-30 surprise Other. I am suprised how easy it is to implement more than its actually needed
W**-31 surprise Other. The tests catch memory leaks. (ie more thorough than what I was expecting)
W**-31 surprise Other. Like the integration of other analysis (mem-check).
W**-34 surprise Other. Testing before writing code
W**-36 surprise Other. It is really nice that when you make a change, all of your previously written tests will catch any errors you may have created.
B***-12 surprise parallel That the test cases are designed in parallel with developing code.
B***-12 surprise passing Just focusing on passing the test and not implementing the complete solution
T**-1 surprise pretty structured It looks a lot more easy than I anticipated. However still need time, its just the beginning so don't know the whole picture yet
L*-4 surprise prevent prevent exception situation.
W**-20 surprise priority That I am worried about testing first and then development.
B***-2 surprise procrastination Procrastinating to break down the problem.
C**-1 surprise productive and fun Feelings of productivity because having tests show that some of the functionality is already implemented (vs writing a big monster of a code and not having the feeling I am any closer to finishing)
C**-1 surprise productivity I'd be surprised to see productivity with that big overhead of testing up front
W**-19 surprise Progress You see the progress. If you feel like "have I thought about xyz?" you write the xyz test.
B***-1 surprise Quick feedback A very quick feedback as to what you're doing wrong.
W**-18 surprise rapid feedback API design via TDD? Feels like API should be done before you start testing. The one positive approach here is that it does force you to design an API that is testable.
W**-21 surprise Red-to-Green 1. Address one change at a time 2. Its okay to write failing test and fix it 3. Refactor as you write test
F**-1 surprise reduce debug time Increase development time at first but reduce the debugging time later
C*****-2 surprise regression How quickly the unit tests provided a simple regression test suite.
W**-18 surprise regressions structural changes may cause some detective work to get underway, clearly tracking back regressions takes practice.
L*-4 surprise RegressionTest Regression Test automatically.
V****-2 surprise requirements That it was possible to get functioning code without a full understanding all the requirements at the start
Z**-1 surprise requirements No mention of requirements or how they feed into tests.
B***-11 surprise Reversed Writing code to fit test rather than the other way around.
W**-21 surprise robust code Earlier our code drives the what tests needs to be written, With this approach the UTs drives the code implementation. Gradually code become so robust, that it will ready for any test case
L*-4 surprise Safety nets TDD makes me stick to green when i make mistake.
D****-2 surprise safety-first That I ever dared to touch legacy code or develop new code without the safety net of continuous and automatic verification.
C*****-2 surprise satisfying The small victories of passing one test at a time were satisfying.
W**-21 surprise short With how little implementation you can get away. And, how clean this implementation is.
B**-1 surprise Simple Fake before you make it. It's seems pretty easy to start your testing when you fake the result first. It allows you to get started faster and worry about the details later.
C**-1 surprise simple Simple concept
L*-4 surprise simple Test code is very simple
Z**-1 surprise simpler It feels like once you get used to it, it's actually easier to do TDD than DLP. Less thinking required. Don't need to hold the entire class in your head, rather fix bugs as they come up.
B**-1 surprise simplicity How simple TDD can make programming.
B**-1 surprise simplicity How simple TDD can make programming.
B**-1 surprise Simplicity The simplicity of some of the tests
M***-1 surprise simplicity the simplicity so far
M***-1 surprise simplicity Its simple to write tests
C*****-2 surprise SLOW I felt that the steps/increments were a bit small.
B**-1 surprise small steps how incremental the procedure can be
M***-1 surprise SMALL steps The immense small steps taken. Not only single code changes tested, but also the compiler/linker error steps. Don't see the benefit of those individual steps (yet).
T**-1 surprise small steps About making changes in quite as small pieces.
L*-4 surprise solid code It is permitted to write code only to pass test cases regardless of its quality. But I believe that I can complement it by refactoring based on existing test cases.
B***-12 surprise Speed The speed with which I could write test cases and functionality simultaneously. I expected it to be more time intensive.
C**-1 surprise speed By doing it in smaller increments than I generally tend to it is possible to get from start to finish more quickly than my tendency to build code, then the tests, then fix the code, iterate.
V**-1 surprise speed It was faster than I thought.
W**-18 surprise speed How rapid it can be to iteratively add functionality.
W**-21 surprise straightforward It is far more straightforward than first thought.
F**-1 surprise Strong Very easy, simple for understand
D****-2 surprise Surprise Its not as easy to write code under the TDD paradigm than I thought it would be.
F**-1 surprise surprise We don't need to think about many coner case to much after develop a feature/software because TDD helps us in developing process.
V****-2 surprise systematic solution There is a systematic way to avoid creating bugs while writing codes.
A*-1 surprise TDD is different than I thought. That you write things you know is going to fail.
A*-2 surprise TDD is different than I thought. felt relaxed while coding
A*-2 surprise TDD is different than I thought. surprise test
B***-13 surprise TDD is different than I thought. That it is truly test driven development - tests drive the development like cart driving the horse.
B***-13 surprise TDD is different than I thought. That it is truly test driven development - tests drive the development like cart driving the horse.
C****-25 surprise TDD is different than I thought. I've never mocked out functionality so heavily (e.g. static buffer allocation in lieu of the "final" malloc-based solution) in situ. Definitely a new way of coding for me.
C****-25 surprise TDD is different than I thought. I thought that one writes the tests up front. I did not know it is a structured approach.
C****-25 surprise TDD is different than I thought. The name. I think it's wrong. This isn't testing.
C****-25 surprise TDD is different than I thought. it is fun :)
C**-1 surprise TDD is different than I thought. It is more of a practice/mindset than a methodology
E*-1 surprise TDD is different than I thought. I was surprised by how iterative it was.
E*-1 surprise TDD is different than I thought. not what I expected
E*-1 surprise TDD is different than I thought. not what I expected
J***-1 surprise TDD is different than I thought. Encourages procrastination
J***-1 surprise TDD is different than I thought. The fact that the name aptly describes the process. I thought it was going to be a framework for unit tests, not changing the way development happens.
J***-1 surprise TDD is different than I thought. test surprise
N***-1 surprise TDD is different than I thought. It's different than what was my initial impression.
R**-2 surprise TDD is different than I thought. How hard it actually is, to stick to the process and only change code parts relevant for the current test to work.
R**-3 surprise TDD is different than I thought. You start first writing the test before you start with the solution
S***-1 surprise TDD is different than I thought. The step-by-step approach is different than the "usual" tests that I write.
W**-22 surprise TDD is different than I thought. it is quick to add test, run and get feedback
W**-23 surprise TDD is different than I thought. concern 1024
W**-26 surprise TDD is different than I thought. Conceptually, its a lot simpler to execute than I thought. Practically, I just need to practice more coding in general to be faster in my TDD
W**-29 surprise TDD is different than I thought. Different way to look at the problem.
W**-30 surprise TDD is different than I thought. That the steps would be that SMALL
W**-30 surprise TDD is different than I thought. surprissed that so many people could have so many different issuse/problems with the first getting started... examples! This is hard stuff! Changing a mind.
W**-34 surprise TDD is different than I thought. I'm surprised at how horrible my test cases are, and the amount of "Fixing" I have to do on my test cases.
W**-34 surprise TDD is different than I thought. I didn't know such a pre-canned test environment existed.
W**-34 surprise TDD is different than I thought. To test one feature implementation, it could need multiple TDD test cases to cover this single feature.
W**-35 surprise TDD is different than I thought. Writing Test code before doing the "right" stuff!
W**-35 surprise TDD is different than I thought. Up to now "strange" procedure.
W**-35 surprise TDD is different than I thought. One surprising aspect is how different it feels to implement TDD versus learning about it.
V****-2 surprise TDD solves corners It is surprisingly good tool to verify the corner cases in very user friendly framework.
A**-1 surprise TDD was easier than I thought. How easy it is to start writing and running test from the begging
J***-1 surprise TDD was easier than I thought. It's pretty easy and fun :)
M**-1 surprise TDD was easier than I thought. It was relatively easy.
R**-2 surprise TDD was easier than I thought. I didn't have to throw away much "fake" code
S***-1 surprise TDD was easier than I thought. I thought this was going to be more much messier than it ended up being. The test environment is really low overhead.
S***-1 surprise TDD was easier than I thought. It's a lightweight / simple process
T*-1 surprise TDD was easier than I thought. Nice development environment
T*-2 surprise TDD was easier than I thought. that is more easy to do than expected (once the tool setup is done)
W**-24 surprise TDD was easier than I thought. There is not much to it, is like eating an elephant "one spoon at the time."
W**-26 surprise TDD was easier than I thought. In many ways, its simple.
W**-27 surprise TDD was easier than I thought. Its simple!
W**-27 surprise TDD was easier than I thought. Not sure whether we write too many tests or too little?
W**-27 surprise TDD was easier than I thought. Easy to work with
W**-28 surprise TDD was easier than I thought. That you can "fake it 'til you make it" and make it like a game in a way, making the implementation just enough to past the tests. It's really a lot of fun (Way more fun than testing after!)
W**-30 surprise TDD was easier than I thought. It's straight forward and simple.
W**-32 surprise TDD was easier than I thought. How easy it was.
W**-34 surprise TDD was easier than I thought. Degree of feedback from the tool, and it was easier to use than expected.
W**-35 surprise TDD was easier than I thought. How easy it is
W**-35 surprise TDD was easier than I thought. Less complex, than I thought.
W**-36 surprise TDD was easier than I thought. Catching problems earlier and realizing how often as developers we get ahead of ourselves.
W**-36 surprise TDD was easier than I thought. I was surprised at how fun it is to write code to tests. It's like adding another layer to the puzzle.
C**-1 surprise tdd_cycle How quickly it was to adjust to the TDD cycle.
F**-1 surprise test before code Think about test before coding
L*-4 surprise test coverage I felt it is not easy to make test design for good test coverage
B**-1 surprise test reliant The tests can be written incorrectly to pass code that does not work.
W**-19 surprise Test Tool Didnt expect some nice feedback that CPPUTEST gave me when tests failed.
A**-1 surprise That it works! Easy framework, keep production code simple
C****-25 surprise That it works! If test plan is covering all requirements, we end up developing everything that is needed.
J***-1 surprise That it works! Its ability to catch errors with each line of code I write.
M**-1 surprise That it works! It was easier than I thought
R**-2 surprise That it works! It's easy to start with
R**-3 surprise That it works! helps in in maintaining a continuous focus on software quality
T*-1 surprise That it works! in every step it is clear what is working and you can exactly prove it
T*-2 surprise That it works! It works! mistakes are easy to identify in time
W**-22 surprise That it works! It surprised me how effective and well it worked.
W**-22 surprise That it works! It surprised me how effective and well it worked.
W**-24 surprise That it works! It works
W**-28 surprise That it works! How useful the incremental tests are at finding mistakes in my code. It makes it much easier to track down where the faults are coming from.
W**-30 surprise That it works! The number of bugs that were detected by tests.
W**-35 surprise That it works! That the test was written for us to complete the exercise.
A**-1 surprise The small steps! That you at the beginnign you don't have to think about that complete algorithm, just make the minimun to make the tests pass
A**-1 surprise The small steps! Incremental coding, writing the tests first and make them fail before coding
A**-1 surprise The small steps! Both implementation and validation in one.
A**-1 surprise The small steps! A different approach/view to deal with new modules programming
A**-1 surprise The small steps! TDD is so different, all the time you need to test with small steps and I think the programmers think too fast and in this case is negative for the deployment of the tests.
A**-1 surprise The small steps! The structure of it can assure you that you didn't leave any code without testing.
A*-1 surprise The small steps! The micro steps of it
A*-1 surprise The small steps! Doing the TDD should be made in small steps.
A*-1 surprise The small steps! Why didn't I learn about this at University?
A*-1 surprise The small steps! The small steps
A*-2 surprise The small steps! -There can be a lot of debugging for writing tests. -It helps you to focus on more specific tasks.
B***-13 surprise The small steps! The flow of using it can be smooth and efficient.
B***-13 surprise The small steps! I am surprised by the step of writing test code that is designed not to compile, verifying that it does not compile, and then starting to make changes to the actual code.
B***-13 surprise The small steps! At way the design is slowly taking shape, driven by the tests.
C****-25 surprise The small steps! It was much easier to start tackling the problem slowly with TDD than going all in coding.
C****-25 surprise The small steps! It was nice to write code incrementally
C**-1 surprise The small steps! It is refreshing way to see in incremental steps with tests tied with them
E*-1 surprise The small steps! Granular Iterative Approach
E*-1 surprise The small steps! I was surprised at how little code was needed to pass each test.
E*-1 surprise The small steps! I was surprised how things started to click as we moved along with the code. it was surprising how hard it can be to step back and look at the smaller steps rather than just focusing on the end goal.
E*-1 surprise The small steps! Its a different way to test/write code, which once a person fully understands, could greatly benefit an organization.
J***-1 surprise The small steps! How doing the least work possible to a pass a test makes the most sense.
J***-1 surprise The small steps! The code for the first few tests are sparse
J***-1 surprise The small steps! It feels tedious at first but I can see how it helps ensure expected behavior at each step. It's still only as good as your ability to think up test-cases though.
J***-1 surprise The small steps! Small steps!
M**-1 surprise The small steps! I'm surprised I have not been using this all along
M**-1 surprise The small steps! It is hard to do SMALL changes.
M**-1 surprise The small steps! Using just the small steps to get the buffer working by just using test cases.
M**-1 surprise The small steps! train me how to *hack* the code as going into the exercise.
R**-1 surprise The small steps! You can produce a lot of positive test results without having any functionality. return 42
R**-1 surprise The small steps! I was surprised that concerns can be separated much more easily.
R**-1 surprise The small steps! Sometimes it feels weird to write such a small amount of code, but I suppose it gives a good granularity of what can fail without verifying.
R**-1 surprise The small steps! The steps are so small... it takes some extra thinking I'm not really used to :)
R**-2 surprise The small steps! The really small steps... functions are doing nothing at the beginning.
R**-2 surprise The small steps! Even if i wrote the tests before the implementation in the past, i almost never gone so much small steps. Only for known edge-cases.
R**-2 surprise The small steps! small steps, but it seems to work
R**-3 surprise The small steps! How hard it can be to only take such small steps.
R**-3 surprise The small steps! It is difficult to not write directly a full implementation.
R**-3 surprise The small steps! That you don't do any implementation before the tests.
R**-3 surprise The small steps! - The Tooling - The simplicity of the individual tests
R**-3 surprise The small steps! Before I thinked it was wlow to make TDD, in fact it's pretty fast. I permit to focus on only one task/problem one by one. It's needed to really split in very very small steps
S***-1 surprise The small steps! It's a lot of compiling and rerunning tests. On larger code bases (if the code is dependent on it), this could take some significant time.
S***-1 surprise The small steps! Tests can be very simple and don't have to test complicated operations.
T*-1 surprise The small steps! Test conacept should be clear already before, is this every time the case ?
T*-1 surprise The small steps! I actually like the splitting. I helps to improve coverage and structure. But needs development time ...
T*-1 surprise The small steps! only think to the next step 'Live today' ;)
T*-1 surprise The small steps! Certain success with dummy code
T*-2 surprise The small steps! Very small work steps.
U**-1 surprise The small steps! each small steps make sure the existing code works.
U**-1 surprise The small steps! Code changes are very small
U**-1 surprise The small steps! It is fun
U**-1 surprise The small steps! I'm surprised how production code grow up. (but I also see situations where, using TDD, it does not happens)
U**-1 surprise The small steps! That even with TDD, your website crashes!
W**-22 surprise The small steps! alot smaller steps taken to be diligent about writing code
W**-22 surprise The small steps! As a generic method it surely has a large spectrum of applications
W**-22 surprise The small steps! How hard it is to "compile" (test) the code so often.
W**-22 surprise The small steps! Testing each incremental change
W**-22 surprise The small steps! Your building frequently and having an expectation of what it will complain about. You're not necessarily looking to get a pass.
W**-23 surprise The small steps! The code coverage integration was new to me. I think it is there to make sure you've tested everything you write.
W**-23 surprise The small steps! How one can tease out functionality to get to really fine granularity on logic
W**-23 surprise The small steps! How small steps should actually be
W**-24 surprise The small steps! the fast feedback loop helps keep pace and momentum moving forward.
W**-24 surprise The small steps! I found it easier to construct a complex test by adding 1 test at a time and checking it.
W**-24 surprise The small steps! the step-by-step process. I originally believed the process to be: 1. write as many tests as you can think of and have them ALL fail 2. Code to satisfy functionality of all those tests 3. PASS tests
W**-25 surprise The small steps! Writing test cases instead of design is still very counterintuitive.
W**-27 surprise The small steps! It is great way to focus the mind on small and incremental details in a design.
W**-27 surprise The small steps! Code is written in very small steps makeing it easier to impliment.
W**-27 surprise The small steps! You can face a problem with small steps.
W**-28 surprise The small steps! How confident I am in my code after passing the tests.
W**-29 surprise The small steps! Literally the tiny steps of doing the development.
W**-29 surprise The small steps! How hard it was to take very small steps - even when I was trying to take the smallest step, I still stored the value prematurely (I could have worked only with the indices).
W**-30 surprise The small steps! Now I have to think of taking small steps for my coding approach. I have to learn this from scratch.
W**-30 surprise The small steps! TDD is an overall weird experience. fun, but weird as you have said before the exercise.
W**-30 surprise The small steps! The fact that I'm forced to progress sequentially and not able to just implement the functionality from scratch.
W**-31 surprise The small steps! I like the test environment - makes it easy to follow the process. I'm curious to see how it will be applied to IDE's and embedded environments.
W**-32 surprise The small steps! "Do the simplest thing that could possibly work"
W**-32 surprise The small steps! How many times I write extra implementation that's untested.
W**-32 surprise The small steps! Some assumptions even for simplest tasks can get you.
W**-32 surprise The small steps! The small size and frequency of the test/code cycles.
W**-34 surprise The small steps! I appreciate the smaller steps during the development.
W**-34 surprise The small steps! Incremental testing and implementation.
W**-35 surprise The small steps! The granularity of the steps.
W**-35 surprise The small steps! It usually takes a bit more time when starting with a new software component, but one will make up for that later on.
W**-35 surprise The small steps! Getting the application ready step by step is really nice. The "basics first" apporach is nice.
W**-35 surprise The small steps! It was surprising that most of the tests just involved returns
W**-35 surprise The small steps! It is slightly more frustrating and more enjoyable at the same time to go in small steps.
W**-35 surprise The small steps! How small the development steps that you take can be. I was expecting bigger, more comprehensive iterations.
W**-35 surprise The small steps! Take baby steps. Make it simpler first, test it, and then gradually increase complexity.
W**-35 surprise The small steps! The method can be applied to different programming languages, probably.
W**-35 surprise The small steps! small steps
W**-35 surprise The small steps! The surprise was the same as my positive - I liked how much less I had to think when I actually had to code. Thinking is just done in the tests.
W**-35 surprise The small steps! initial goal gets split into (very) small pieces, with each beeing easy to test
W**-36 surprise The small steps! How small the steps are.
W**-36 surprise The small steps! I like the ideas behind TDD, but I'm frustrated with the inability to move forward with the right answer because I can't move as fast as I'd like.
W**-36 surprise The small steps! I did not thing the steps would be so small. I think this makes it appear slow.
W**-36 surprise The small steps! My favorite thing about TDD is thinking in small steps. When you think in small steps, function/class interfaces are as simple as they need to be. The repo is smaller because you know YAGNI earlier.
W**-36 surprise The small steps! How thorough the tests are and seems if done correctly bugs could be caught ahead of time even if the application code doesn't use the method yet.
W**-19 surprise Thinking A new way of thinking. Only making changes to production code if it's driven by a new test is an interesting way to develop.
W**-18 surprise time The development speed was a bit slower, but more evenly paced with less staring - overall a win time wise.
W**-18 surprise time more time consuming than expected
V**-1 surprise time saver How easy it is to catch what could otherwise be hard issues to solve
F**-1 surprise totally new First time I know TDD
W**-18 surprise Trap I am surprised how easy it is to fall into a trap with a design that would never meet requirements when using TDD and how easy it is to miss test cases when not designing up front.
Z**-1 surprise unexpected bugs Often finds bugs in code I was quite confident about, did not happen in this particular exercise but I've had such experiences in the past
M***-1 surprise useful You can always find meaningful test cases even if the problem seems trivial
F**-1 surprise usefully Yeah! It's so usefully to test and check the code. It's very usefully to save the time for fixing bugs.
M***-1 surprise web ui very easily run in the web ui
Z**-1 surprise Wild Explicitly de-emphasizing requirements on initial iteration cycles.
W**-18 surprise wondering The lack of forward thinking in writing code that will knowingly fail tests later.
T**-1 surprise workflow. Such a different workflow.
Z**-1 surprise works it works!!
B***-12 surprise Zero Nothing. I have been exposed to TDD before.