What surprised 766 people about their first TDD experience

Course code Kind In a Word Impressions
A******-2 surprise An implementation came out pretty quickly, with reasonable confidence to its correctness.
A******-2 surprise It is simple to implement and it helps the developer to determine what to focus on next.
A******-2 surprise The iteration step size is smaller than I'm normally comfortable with.
A******-2 surprise It is more simple and concise than I originally thought it would be.
A******-2 surprise The relative ease of development and how quickly developers can go from test to dev.
A******-2 surprise No surprise yet
A******-2 surprise I'm not sure I was necessarily surprised by anything.
B**-1 surprise Bug-resist It definitely has potential to do great in catching bugs early
B**-1 surprise easy prevence How it is easy to prevent silly and hidden bugs.
B**-1 surprise failure That we are supposed to make it fail first
B**-1 surprise interesting interesting
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.
B**-1 surprise not at all I already use it.
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.
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
B**-1 surprise small steps how incremental the procedure can be
B**-1 surprise test reliant The tests can be written incorrectly to pass code that does not work.
B***-10 surprise It didn't take much longer than it would to just code the module with no tests!
B***-10 surprise I knew the structure coming into the class. However, working through examples helps to underscore the value.
B***-10 surprise no surprises, a matter of adjusting to something different to me.
B***-10 surprise The simplicity at the core of the concept.
B***-10 surprise How much time has to be spent thinking about testing up front
B***-10 surprise Procrastinating implementation will help later.
B***-10 surprise It seems very inefficient for the time being, but hopefully things will change for the better as the code develop.
B***-10 surprise Nothing as yet.
B***-10 surprise How small the iterations were, developing the test stub in parallel with the code.
B***-10 surprise How fast you see feedback.
B***-10 surprise How much fun it is to get the green pass circle.
B***-10 surprise it helps you flesh out your public API at an earlier stage
B***-10 surprise How tough it is to change the mindset in developing code. I am very used to the non TDD way of developing.
B***-10 surprise It is more tedious than I was expecting.
B***-10 surprise I thought the 'test harness' was an actual piece of hardware that needed to be custom built.
B***-10 surprise The level of decomposition to a very tiny elements of the code. What is the acceptable level of decomposition.
B***-11 surprise emergent the way a working and complete code-base appears out of thin-air
B***-11 surprise force-fail Forcing failures as an effective technique.
B***-11 surprise Light? Getting up and running doesn't seem to require much in terms of "infrastructure" to support the framework.
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.
B***-11 surprise Reversed Writing code to fit test rather than the other way around.
B***-12 surprise Fun More enjoyable than I thought
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)
B***-12 surprise incremental more and more completely considered
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
B***-12 surprise Speed The speed with which I could write test cases and functionality simultaneously. I expected it to be more time intensive.
B***-12 surprise Zero Nothing. I have been exposed to TDD before.
B***-13 surprise Code is incomplete for so long. Code is incomplete for so long it makes me want to jump ahead!
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.
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.
B***-13 surprise None. I am surprised that aside from learning the new tools the TTD implementation is straightforward.
B***-13 surprise Nothing. Nothing since I already practice is.
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.
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.
B***-5 surprise surprise 1
B***-6 surprise I've been breaking much more code than if I were to simply write-then-test.
B***-6 surprise Desire - couple this with documentation generation
B***-6 surprise Desire - readable way to tie test to requirement
B***-6 surprise The small size of the programming/test increment (very fine-grained).
B***-6 surprise The fact that you start by writing "dummy" code on purpose in order to pass the first tests.
B***-6 surprise Rein-in the coder-monkey
B***-6 surprise The very first bug that TDD caught for me in my own code. After that I was sold.
B***-6 surprise The tests can find my bugs promptly. So, I can find and fix them very quick.
B***-7 surprise bigger: The test code is a lot bigger than the actual product code.
B***-7 surprise cheating: I can get away with bad code...initially
B***-7 surprise Memory: checking of the testing framework
B***-7 surprise Easy: CPPUtest is surprisingly easy to use.
B***-7 surprise TIME:Software development using TDD is not as time consuming as I had earlier imagined.
B***-7 surprise Expansion: I was surprised to see the level of code expansion be so minimal, and to have several tests pass without needing to do additional work.
B***-7 surprise simplicity: TDD makes you slow down and focus on one specific behavior of your code that you want to test. Its easy to get ahead of yourself and think about all the complicated edge case scenarios but you really should focus on the common scenarios first, then worry about handling more complicated things later.
B***-7 surprise Incremental: How small the increments are. Fake it till you make it.
B***-7 surprise knowledge: It seemed like the logic of doing more work towards the resulting code was going to confuse me more, but I think I have a better understanding of each function by having to revisit the functions in multiple iterations to constantly add functionality.
B***-7 surprise How quickly we found the bugs that we introduced.
B***-7 surprise friendly test environment: Developing the test cases drives developing my real functions.
B***-7 surprise progress moves fast since the thinking is less.
B***-7 surprise small steps: The steps are much smaller than expected.
B***-7 surprise how many tests has to be done for simple function
B***-7 surprise Cpp: Using C++ in Embedded Systems was a surprise
B***-8 surprise nothing
B***-8 surprise How quickly it led to the completion of a feature.
B***-8 surprise It's easy once you get the hang of it
B***-8 surprise iterations were smaller/simpler than expected
B***-8 surprise How easy it is to find and fix a bug, that would have otherwise taken a lot longer.
B***-8 surprise Change my think flow about writing a code. I used to think how to write it correctly and missed many corner cases. TDD make me thinking what a code can go wrong first.
B***-8 surprise No surprises.
B***-9 surprise It started moving faster toward the end. Especially after the wraparound issue was resolved. Or I just got lazy and cheated without realizing it.
B***-9 surprise helped me develop my code in the right increments. hopefully, will end up with code that will not break
B***-9 surprise It doesn't negatively impact development speed as much as expected.
B***-9 surprise The 'backward' thinking of making things fail, taking shortcuts and 'faking' it instead of making them just right the first time. This also seems like an inherent overhead of TDD.
B***-9 surprise I went off on my own idea and it still produced a correct solution
B**-1 surprise How quickly I picked up the basic premise
B**-1 surprise NA
B**-1 surprise Easy to learn
B**-1 surprise It was easier to get used to than I was expecting
B**-1 surprise Nothing surprises me anymore.
B**-1 surprise it doesn't feel like as much extra work as I expected
B**-1 surprise
B**-1 surprise my system had bugs, it surprised me when I found them. :)
B**-1 surprise Today's presentation seemed focused on writing tests while you are developing rather than before you are developing. I might have expected an empty interface with tests against it prior to writing the CPP.
B**-1 surprise It is ok to hardcode things when you first write them.
B**-1 surprise I didn't expect to like it as much as I do.
B*-1 surprise Nothing, since I started doing it many years ago.
B*-1 surprise It was surprising how quickly the functionality evolved when thinking about it piece by piece
B*-1 surprise not much, had traning before.
B*-1 surprise nothing
B*-1 surprise It identified small defects that would normally not get found or fixed right away.
B*-1 surprise Quick feedback
B*-1 surprise How differnt the approach is from traditional design methodologies.
B*-1 surprise No surprises, benefits are imminent
B*-1 surprise It was surprisingly fun.
B*-1 surprise It delivers robust and refactored code.
B*-1 surprise The ease at which I could iterate
B*-1 surprise Much harder than I thought.
B*-1 surprise Problems were introduced slowly and much easier to fix
B*-1 surprise How easily developers can occupy themselves with simple problems.
B*-1 surprise The process of TDD didn't seem to bog-down development as much as I was afraid it would.
B*-1 surprise The amount of time spent and still not close to the final solution.
B*-1 surprise while not looking at the larger picture, focusing on smaller units can add value
B*-1 surprise Much harder than I thought. FYI: If you click the "surprised" or "concerned" you links multiple times, it adds multiple entries to the list underneath of it.
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.
B***-1 surprise design You can design the coding and testing then implement them
B***-1 surprise document A uniform way to build and document test cases.
B***-1 surprise fun I found it a lot more fun than what I expected.
B***-1 surprise long-process how long it takes to do TDD
B***-1 surprise nothing Nothing.
B***-1 surprise nothing not sure
B***-1 surprise oops How you can defer design and implementation.
B***-1 surprise Quick feedback A very quick feedback as to what you're doing wrong.
B***-1 surprise how much it helps to learn nuances of the language employed.
B***-1 surprise How easy it is to forget about it.
B***-1 surprise It seems to take a lot of attention to detail.
B***-1 surprise Have not found a surprise moment yet.
B***-1 surprise It is easier than I thought it would be.
B***-1 surprise Faster than I thought it would be.
B***-1 surprise Is not as difficult as I imagined.
B***-1 surprise How testing very simple things (seemingly trivial) at the beginning becomes beneficial once complexity is added to your project.
B***-1 surprise It makes me think about decomposition in a more rigorous way.
B***-1 surprise I've never used a test harness before and the ease of use was a pleasant surprise.
B***-1 surprise It was as I expected.
B***-1 surprise n/a
B***-1 surprise It changes the way you think about coding.
B***-1 surprise Used to think you would write a lot of failing tests up front (roughly mapping to needed features), this last exercise did not have us do that.
B***-1 surprise How much extra code churn it is
B***-1 surprise How effective the methodology was for eventually providing 'conquered territory' of provably correct code.
B***-1 surprise I like to start with a more functional first test case. I feel like we are starting too small with is empty/isfull
B***-1 surprise I shouldn't be surprised, but Tom Voils is a really good pair programmer partner.
B***-1 surprise "Fake it until you make it" works to satisfy a large number of simple tests. It's not until you get to more complicated tests that you need to add the actual functionality.
B***-1 surprise The fake-it-till-you-make-it mentality
B***-1 surprise How easy it was to modify the code to add new features.
B***-1 surprise The baby-step-wise workflow can seem slow and tedious but is actually quite powerful and efficient.
B***-1 surprise It leads to much better interfaces (when you are disciplined about testing only at the interface)
B***-1 surprise A very simple design evolved pretty much on its own. (DTSTTCPW / YAGNI)
B***-1 surprise Faster than I thought it would be.
B***-1 surprise The obligation to write incorrect or incomplete code in service to a methodology rather than applying the methodology to assist in writing correct code (or at least code intended to be correct and complete) the first time.
B***-1 surprise * I had expected it to be about 3X the effort (or 1/3 the velocity) of trad. SW development. I was pleasantly surprised to find it is <= 2X
B***-1 surprise That more people aren't familiar with the pattern, as it follow directly from most people's debugging experiences.
B***-1 surprise I'm surprised you didn't quote Brian Kernighan: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
B***-2 surprise CppUtest Rox! CppUtest continues to be awesome around memory corruption and leaks!
B***-2 surprise disruptive How different it is, when you're actually doing it, from almost anything I have been taught.
B***-2 surprise Flexibility The CppUTest infrastructure seems a good mix of formality and flexibility.
B***-2 surprise integrated Thought it was write test then write code, much more integrated
B***-2 surprise procrastination Procrastinating to break down the problem.
C*****-1 surprise How quickly the number of tests you need grows
C*****-1 surprise Number of tests that is being developed is quite high
C*****-1 surprise the basics of the 'think about what to write next' problem seemed surprisingly natural
C*****-1 surprise I was surprised that it actually moves forward quicker than you'd think
C*****-1 surprise Nothing.
C*****-1 surprise more straight-forward than I expected
C*****-1 surprise It's not much extra effort to build out the tests than developing the code even though there is likely going to be more test code than production code. Seems like the tradeoff of time to write the tests is well worth the time of finding a bug in the field.
C*****-1 surprise That when I really thought about my work process, the real difference ends up being that I do more iteration up front. (Instead of adding a bunch of stuff that may not work.)
C*****-1 surprise I was surprised to see each test case so short - I've usually written one line of 'mutator' code and then tested all relevant 'const getters' to check the visible state of the object.
C*****-1 surprise the apparent ease of implementation while with the instructor. I'll be curious to see if this holds up after a few weeks.
C*****-1 surprise how little the previous tests need to change even as code evolves a lot.
C*****-2 surprise boring how boring it was
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.
C*****-2 surprise lies easier than you think to have bad code pass
C*****-2 surprise nothing I've been doing this for personal side projects, so not a surprise.
C*****-2 surprise regression How quickly the unit tests provided a simple regression test suite.
C*****-2 surprise satisfying The small victories of passing one test at a time were satisfying.
C*****-2 surprise SLOW I felt that the steps/increments were a bit small.
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**-1 surprise convenient A complex problem is broken down in manageable pieces.
C**-1 surprise easy Had no expectations, but it has been easier to follow than what I anticipated
C**-1 surprise fake it is OK to 'fake it 'till you make it'
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
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)
C**-1 surprise mistakes That I write the code as well as the tests.
C**-1 surprise nice It's pretty straight forward.
C**-1 surprise no surprises There is no suprise really. Its known but the value is realised when everbody practises it diligently.
C**-1 surprise Not yet surprised I am not easily surprised :)
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
C**-1 surprise simple Simple concept
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.
C**-1 surprise tdd_cycle How quickly it was to adjust to the TDD cycle.
C***-1 surprise - I like it a bit more than I thought I might. I actually write production code in a similar way in that I write a little, then manually test it, then write a little more, etc... The nice thing here is that this will give me tests that I don't have to do manually forevermore.
C***-1 surprise I read the book. Plus I try to do a minimalist version of TDD normally. I can't think of anything.
C***-1 surprise So far, it's enjoyable.
C***-1 surprise The test harness is powerful.
C***-1 surprise That I could learn something and improve my code by entering code that forced it to pass. Example: hard code a return value and it passes. This shows you need another test.
C***-1 surprise How it forces you to build functionality in incremental steps. ("I can't do that function until I've got this function implemented.")
C***-1 surprise It feels like it can speed up exponentially once you lay enough of the ground work. Recycling old, tested test-code is a pretty good feeling. Past-me is doing a lot of work for present-me.
C***-1 surprise Nothing
C***-1 surprise once setup, it flowed nicely and forced me to correct and grow the code as needed. Those were the things I was hesitant about forgetting to do in the beginning.
C***-1 surprise The methodology work far better than I was expecting.
C***-1 surprise It can do more than I expected (by faking the input/output/return)
C****-15 surprise It's simple.
C****-15 surprise break your code in order to fix it
C****-15 surprise I have heard of Junit unit for some time. My understanding that junit is used for unit testing. I thought TDD was more than that. I guess TDD is the process of continuously test with dev
C****-15 surprise The concept seems to be so simple yet powerful.
C****-15 surprise x
C****-19 surprise I quite liked only writing the minimum code needed to fulfil the test
C****-19 surprise It seems easier to do pair programming.
C****-19 surprise It not only helps me to write the code, but potentially design the architecture.
C****-19 surprise
C****-19 surprise How easy it was to write a fundamentally broken implementation that still passed a large number of tests - though note that we had not completed all the tests when we stopped the exercise, so hopefully this would have righted itself.
C****-19 surprise even doing small/simple exercises I managed to find the bugs very easily AND without a debugger
C****-19 surprise No mention of how this applies to legacy code yet
C****-19 surprise It is easier to refactor not only the code but also the test.
C****-21 surprise The exploratory nature of the process.
C****-21 surprise Test can pass without the whole function written
C****-21 surprise Move Fast and Issue are fixed immediately
C****-21 surprise The method is simple enough to understand: write your test cases and let that drive your design. But actually going through it, and restraining yourself from writing more code than necessary, was surprisingly difficult. It is very easy to jump ahead because you know what your code needs to be eventually, but with TDD you are coding as you test and you should not move forward with untested code. It is not intuitive: I am very used to writing small portions and testing small portions, and I always thought that was a good process.
C****-22 surprise The coverage of code being tested by TDD.
C****-22 surprise Not much: I already knew it and I'm trying to use it as often as possible at work...
C****-22 surprise Nothing tbh
C****-22 surprise
C****-22 surprise Surprised how hard it was to reign ourselves back from doing too much all the time.
C****-22 surprise Surprised by the dividends (mistakes revealed immediately) from taking this highly iterative approach.
C****-22 surprise how hard to break the task down to small incremental steps enough to tdd, something I usually do when learning a new language
C****-22 surprise incremental development
C****-22 surprise TDD helps you code rather than validate it.
C****-23 surprise How important it is to avoid analysis paralysis.
C****-23 surprise Despite spending a lot of time on tests, progress is fast
C****-23 surprise Very easy to get ahead of one self and write code without coverage.
C****-23 surprise How many tests we could get to pass without having implemented anything useful
C****-23 surprise The number of small errors and typo's that are caught when writing tests.
C****-23 surprise It acts as nice documentation and examples of how to use a module
C****-23 surprise How it makes you realise how many small mistakes one does during coding
C****-23 surprise My previous attempts at TDD have not been anything like this. It is a completely new way to think about the code I write!
C****-23 surprise How fun it is
C****-24 surprise NA
C****-24 surprise Need to think different.
C****-24 surprise Test Driven Development. My initial understanding (which has now changed) of TDD was writing modular code first in order to test it after implementation, I was wrong to some degree.
C****-24 surprise The philosophy itself is new: Don't put logic in until your tests demand it.
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****-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****-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****-25 surprise That it works! If test plan is covering all requirements, we end up developing everything that is needed.
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 Quick progress
C**-1 surprise ease of test development
C**-1 surprise What comprises "just enough" to pass a test is quite subjective
C**-1 surprise That I'd slipped into writing code before tests over the past few years.
C**-1 surprise Easy to work through the errors
C**-1 surprise The idea of writing the test before function prototyping
C**-1 surprise Nothing much so far.
C**-1 surprise The fact that it is iterative and not all tests need to be created up front
C**-1 surprise The ability to write code that you know is wrong, but still passes the tests. Maybe this isn't that surprising as we often write code that is wrong, but still is released.
C**-1 surprise The vast amount of test cases you have to write for a simple FIFO code.
C**-1 surprise Having to make small incremental changes per test
C**-1 surprise The number of steps
C**-2 surprise You really have to write test first for each character in your code.
C**-2 surprise How easy it is to combine multiple aspects together as a single one without consciously intending to.
C**-2 surprise How small the development steps are
C**-2 surprise The free lunch.
C**-2 surprise How difficult it is to stop myself writing code that wouldn't be tested
C**-2 surprise nothing
C**-2 surprise Nothing much at the moment, just trying to get into the TDD mind-set.
C**-2 surprise Nothing
C**-2 surprise I like it !
C**-2 surprise It works!!
C**-2 surprise resistance in the room
C**-3 surprise Test bench caught illegal memory accesses.
C**-3 surprise Tests sometimes fail/pass when you don't expect them to.
C**-3 surprise Slower than I expected.
C**-3 surprise Test framework better than expected.
C**-3 surprise The speed with which test driven development with deferred implementation leads to a good solution.
C**-3 surprise how easy it was to do
C**-3 surprise How bug introduced by code improvement can be quickly detected.
C**-3 surprise simplicity
C**-3 surprise Probably the code we write this way will be error free but I wonder how will we manage a big project with this approach
C**-3 surprise simplicity
C***-1 surprise Small incremental approach
C***-1 surprise how similar it is to what I've been doing. Difference is I don't get to keep my test code
C***-1 surprise Waiting for one
C***-1 surprise jumping directly into test cases without spending time understanding details.
C***-1 surprise It was a straightforward process.
C***-1 surprise Able to find out different scenarios which might have thought but may be skipped in implementation period.
C***-1 surprise I am surprised to see immediate hands on, which is good thing. Most of the past training I have seen, we had a lot of lecture, less hands on
C***-2 surprise It works! (for the small example)
C***-2 surprise Enjoyable :)
C***-2 surprise Helps to drive design
C***-2 surprise Too much refactoring / re-coding.
C***-2 surprise The resulting code less efficient than it would with design first
C***-2 surprise Fast execution time of TDD cases and memory violation checks
C***-2 surprise It reminds me of how you teach a child to program. "Put in printf("Hello World!"), see how it prints! What if you want to print it 5 times? What if you want to input a different name?" With every step, you are demoing that the code is operable and doing what was expected.
C***-2 surprise I got hyper-focused on the specific test and could lose sight of the overall feature.
C***-2 surprise Even hardcoded and tested code is tested code, until time comes to change hardcoding, because other tests written for additional functionality start failing tests for hard coded implementation
C***-2 surprise Really helps to understand which is essential and which is not.
C***-2 surprise low industry adoption
C***-2 surprise I guess, the first impression i had till the concept become clear was, it is just too laborious.. but after doing 3/4th of the exercise, I felt I can do it... I have lots of scenarios that this particular exercise didn't answer, so it is upto the developer to put all those test cases...but seriously I always thought how to do the unit testing... TDD answered it .....
C***-1 surprise compiler errors count as errors
D**-2 surprise Its easy to get into a rhythm.
D**-2 surprise Not really, but emotions were still positive :)
D**-2 surprise How many steps may be performed to solve a simple problem.
D**-2 surprise Simplicity
D****-2 surprise difficulty Everyone seemed to struggle a bit, even ppl who've had experience w/testing.
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.
D****-2 surprise like it I like it more than I thought I would
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.
D****-2 surprise Surprise Its not as easy to write code under the TDD paradigm than I thought it would be.
E**-1 surprise it's really straight forward
E**-1 surprise To force me to write a test that doesn't pass
E**-1 surprise Writing code knowing it's bad is surprising and I'm afraid I'll sometime forget to efficiently fix it.
E**-1 surprise The code programming method. The code must be written step by step.
E**-1 surprise the fact that we have to write just enough code to success a test
E**-1 surprise Progress is faster than expected.
E**-1 surprise More faster than I thought
E**-1 surprise Even though we do just the minimum possible the code tend to work by the end
E**-1 surprise It seems to be better to check only one thing in one test, although initially I thought it is safer to always check everything we can.
E**-1 surprise Simple development steps.
E**-1 surprise how many typos I can write without spellchecker.
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.
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
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
F**-1 surprise Improvement This course will help developers avoid bugs.
F**-1 surprise reduce debug time Increase development time at first but reduce the debugging time later
F**-1 surprise Strong Very easy, simple for understand
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.
F**-1 surprise test before code Think about test before coding
F**-1 surprise totally new First time I know TDD
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.
H*-1 surprise The development can be done.
H*-1 surprise How small the increments of test and functionality development are.
H*-1 surprise I'm surprised at how often my tests failed when I thought they should have passed.
H*-1 surprise Test framework seems easy to learn.
H*-1 surprise I sort of anticipated this, since I had already started on the book, but I'm surprised at how hard it is to take the small steps. We seem to naturally want to get all the tests and all the code out of our heads all at once instead of taking the small steps. It's like the "microcycle" goes against the way we've learned to work. It feels like an interruption to our normal work flow.
H*-1 surprise Without structured design nor intention - but just an idea of what I wanted - I was able to create a product with a minimal amount of code that I feel confident about
H*-1 surprise How you don't write all of your tests initially, but rather develop them with your code
H*-1 surprise I was surprised that the goal isn't to create all of your tests at once and then write code to satisfy them all.
H*-1 surprise n/a
H***-1 surprise Free Lunch !
H***-1 surprise nothing
H***-1 surprise Didn't realize that TDD was used throughout the development process - I thought the test cases would be written/applied after the code was developed
H***-1 surprise That I like it as much as I've found.
H***-1 surprise What was surprising is that the test is written before the actual code is written
H***-1 surprise That its not more widespread in embedded world :)
H***-1 surprise I had a great deal of Aha moments with c; which makes this fun.
H***-1 surprise A lot to do for a simple test.
H***-1 surprise Was able to generate better structured code than just winging it.
H***-1 surprise nothing
H***-1 surprise Tee way it's done.
H***-1 surprise While i am coding, i need to verify and debug my code even though my code is not mature.
J***-1 surprise Almost automaticly writing tests. The interface is simpler that I imagined -- getting a testing environment set up is usually frustrating
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
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.
J***-1 surprise None. It seems to be a very thorough way of making your code robust
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
J***-1 surprise TDD was easier than I thought. It's pretty easy and fun :)
J***-1 surprise That it works! Its ability to catch errors with each line of code I write.
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!
L*-4 surprise Considering_REQ It makes me think deeply about the requirement/design before the implementation.
L*-4 surprise developement Feels like developement, not test
L*-4 surprise easiness It's easier than I thought. It can be automatic.
L*-4 surprise Easy Easy to make TEST code
L*-4 surprise Easy Easy Concepts and Applications
L*-4 surprise flow of coding The flow of coding with TDD seems reasonable.
L*-4 surprise Good Code I surprised TDD could produce good code because it makes me think how to prevent bugs much.
L*-4 surprise handy It's easy and handy
L*-4 surprise managed testcase Get systematically managed testcase
L*-4 surprise many test case success many test cases more as I expect.
L*-4 surprise meaningful It really makes the codes meaningful.
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.
L*-4 surprise prevent prevent exception situation.
L*-4 surprise RegressionTest Regression Test automatically.
L*-4 surprise Safety nets TDD makes me stick to green when i make mistake.
L*-4 surprise simple Test code is very simple
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.
L*-4 surprise test coverage I felt it is not easy to make test design for good test coverage
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.
M***-1 surprise easy to use Not as difficult as expected.
M***-1 surprise I can do this Step by step breaking bigger things up into smaller chunks
M***-1 surprise ItsNeverTooLateToLrn This is a very useful tool for development. I should have known much earlier :)
M***-1 surprise simplicity the simplicity so far
M***-1 surprise simplicity Its simple to write tests
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).
M***-1 surprise useful You can always find meaningful test cases even if the problem seems trivial
M***-1 surprise web ui very easily run in the web ui
M*****-8 surprise nothing yet
M*****-8 surprise Nothing.
M*****-8 surprise That progress could be made without reverting to the debugger.
M*****-8 surprise Came in with little pre-conception. So nothing has surprised so far.
M*****-8 surprise nothing
M*****-8 surprise easy to approach
M*****-8 surprise - easy to learn
M*****-8 surprise Nothing. We work in a similar way.
M*****-8 surprise Nothing
M*****-8 surprise We need to change our way of thinking at the beginning of a program. It will take time to adapt. We may need different person to think and write tests.
M*****-8 surprise nothing yet....
M*****-8 surprise For the moment it is according to what I expected.
M*****-8 surprise It is simple and friendly
M*****-8 surprise Easy test case implementation (divide et impera - divide and conquer)
N**-2 surprise Taking small steps truly lowers the bar for getting started with TDD.
N**-2 surprise The amount on fake implementation on the way.
N**-2 surprise How it reduces the time to launch a product.
N**-2 surprise easy to apply
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
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***-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***-1 surprise TDD is different than I thought. It's different than what was my initial impression.
N***-1 surprise The work-flow itself is jarring.
N***-1 surprise No surprises
N***-1 surprise You spend a lot of time outside of the green zone.
N***-1 surprise Once I new the steps, it seems to flow pretty smoothly.
N***-1 surprise I was surprised at how well I took to it.
N***-1 surprise It really improved my workflow
N***-1 surprise The fake it, instead of make it, philosophy. Didn't expect that.
N***-1 surprise Can't really be surprised when I didn't know what to expect.
N******-2 surprise How writing test and production code can go hand in hand with each other.
N******-2 surprise Looks easier than it is :)
N******-2 surprise TDD led me to the end solution
N******-2 surprise That it acctually drives development and not vice versa.
N******-2 surprise TDD needs different way of solving the problems.
N******-2 surprise > no surprise
O****-1 surprise Hmmmm. No surprises, yet.
O****-1 surprise how many bugs i did
O****-1 surprise the kind of mechanical implementation
O****-1 surprise You need to break development in very small steps
O****-1 surprise The idea itself: To have the tests first.
O****-1 surprise at the moment: nothing
O****-1 surprise the possibility to test immediately the software
O****-1 surprise the speed of developing
O****-1 surprise Proceeding seams to Support step-by-step implementation
O****-1 surprise ?
O****-1 surprise Goes fast trough the learning curve
O****-1 surprise is good feddback
O****-1 surprise That you finish testing and implementation at the same time. You dont have testing work twice due to Automatisation.
P***-1 surprise the number of times incomplete code would pass tests "so far", but then fail the next text.
P***-1 surprise you need to make the test fail first. this is so different from we have been doing before.
P***-1 surprise it made me think all the corner cases.
P***-1 surprise Thinking from 2 different perspective at the same time.
P***-1 surprise It makes you focus on once change at a time.
P***-1 surprise The way the design evolved from the test cases
P***-1 surprise It involves too many steps then expected.
P***-1 surprise it enabled to think about writing code in a different manner
P***-1 surprise Time should be spent to find a way to fail a test case.
P***-1 surprise not so much
P***-1 surprise How difficult it is to make only the change which needs to be made.
P***-1 surprise Once you have the framework, it is easy to write more tests
P***-1 surprise NA
P***-1 surprise How complex can the test cases become? When they become so, are not we complicating too much?
P***-1 surprise No significant surprises.
P***-2 surprise Time consuming
P***-2 surprise NA
P***-2 surprise There was nothing that surprised me
P***-2 surprise It is similar to what was explained in the video. I am happy to see we can be confident of the code we are developing as we go.
P***-2 surprise The way brain functions when challenged with a failing test case.
P***-2 surprise It seems easier to develop test code than traditional development style.
P***-2 surprise Never knew that TDD can save a developer and his/her program a lot more time in future for debugging and solving issues.
P***-2 surprise I don't think that I was surprised
P***-2 surprise that it would detect the memory leak
P***-2 surprise No much surprises
P***-2 surprise
P***-2 surprise Didn't think of write test code first. Always start with coding first, then test.
P***-2 surprise I didn't know about test driven development. Currently we write the code and then test it. This approach is completely opposite.
P***-2 surprise how much upfront work is required. Any suggestions to rapid prototype something and then go back and rework/design using TDD?
P***-3 surprise Coding and testing goes concurrently.
P***-3 surprise Tests can be automated by very simple test cases.
P***-3 surprise Building solution block and block
P***-3 surprise I am thinking differently for how to make the test case rather than writing the proper code for the requirement
P***-3 surprise Ease of writing unit test case.
P***-3 surprise nothing!!
P***-3 surprise We could learn something in this process, such as: how to test our code,how to write our code effectively.
P***-3 surprise Changes the conventional work-flow and provides documentation along the way
P***-3 surprise When development finished, test is finished. And the code works very well.
P***-3 surprise The tool is surprisingly effective. It detected out-of-memory access. I wonder how that works?
P***-3 surprise Good and easy development with TDD
P***-3 surprise Can proceed with implementation once all usecases are identified
P***-3 surprise It's interesting.
P***-1 surprise I caught myself several times leaping ahead in terms of implementation, eventhough I tryied to restrain myself from doing it.
P***-1 surprise How small the iterations were.
P***-1 surprise how naturally it was to start thinking this way
P***-1 surprise the amount of fake stuff you can get away with before having to write real code
P***-1 surprise It is possible to write a lot of incorrect code to get the tests to pass, however this will of course lead to problems later.
P***-1 surprise Its tempting to rush ahead and write more application code than absolutely necessary to pass a test.
P***-1 surprise That it was easier to have a correct implementation after doing refactoring. You get more engaged in developing the code
P***-1 surprise That we were told to simplify the initial implementation in order to make the simple tests pass first, and then gradually make the full implementation. It suprised me how well this worked.
S****-1 surprise No surprise.
S****-1 surprise Simplicity of most test-cases
S****-1 surprise Nothing really surprising.
S****-1 surprise As tests are being created, more aspects of the same function are being verified.
S****-1 surprise A lot of test/code/refactor cycles, 1 step at a time
S****-1 surprise It doesn't take to much extra time compared to not writing the tests.
S****-1 surprise Some changes resulted in other tests (other than the one we were working on) to fail, forcing us to look at the code again
S****-1 surprise It's easy once you get used to it.
S****-1 surprise creating partially wrong production code on purpose in order to follow TDD
S****-1 surprise That you need to pace yourself with implementing the production code. You tend to do more than TDD prescribes.
S****-1 surprise isFull was the hardest
T***-1 surprise 851 surprise 851
T**-1 surprise bugs How many unexpected bugs I write.
T**-1 surprise easy Easy to understand the concept.
T**-1 surprise none none
T**-1 surprise only what's needed Only focusing "on the next thing" ... only adding test functionality up to what you need now/next
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
T**-1 surprise small steps About making changes in quite as small pieces.
T**-1 surprise workflow. Such a different workflow.
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.
U**-1 surprise Code is incomplete for so long. Weak design probably until you have covered all the scenarios.
U**-1 surprise Easier than I thought it would be. It is fun
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
U**-1 surprise Nothing. Nothing
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.
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!
V****-1 surprise I'm not sure if I should be programming. Should I be a manager?
V****-1 surprise How many bugs we wrote that were caught by the tests
V****-1 surprise Even I can do it.
V****-1 surprise How often we were retesting code that we wrote.
V****-1 surprise no surprise.
V****-1 surprise Wasn't what I thought it would be; and I don't know what that was!
V****-1 surprise It is much easier to identify corner cases.
V****-1 surprise Nobody expects the Spanish Inquisition
V****-1 surprise The increments in the example are a lot smaller than I expected.
V****-1 surprise How it catches stupid mistakes
V****-1 surprise Even a manager was able to produce working code
V****-1 surprise The nice cadence to development
V****-1 surprise how many mistakes in logic were actually made along the way.
V****-1 surprise Using the compiler to help write code
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.
V****-2 surprise healthy TDD is a healthy practice as the developer need not concentrate much while developing software
V****-2 surprise insight It provides a good insight into the process of coding
V****-2 surprise integrity write a code that shall work for ALL cases with intended behavior.
V****-2 surprise Nothing Nothing
V****-2 surprise requirements That it was possible to get functioning code without a full understanding all the requirements at the start
V****-2 surprise systematic solution There is a systematic way to avoid creating bugs while writing codes.
V****-2 surprise TDD solves corners It is surprisingly good tool to verify the corner cases in very user friendly framework.
V**-1 surprise #compiles the amount of compilations/builds
V**-1 surprise #compiles the amount of compilations/builds
V**-1 surprise development support Some solutions in the algorithm was already implemented by implementing and solving a smaller part of the problem.
V**-1 surprise easy easy to build/test from the get go. Perhaps not very surprising after all but anyways :D
V**-1 surprise fun it did make writing code more interactive since we saw the result almost immediately
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.
V**-1 surprise LowThreshold How easy it was to get started.
V**-1 surprise LowThreshold How easy it was to get started.
V**-1 surprise Nothing No surprise
V**-1 surprise speed It was faster than I thought.
V**-1 surprise time saver How easy it is to catch what could otherwise be hard issues to solve
W****-1 surprise I thought we were going to be assigned to pairs by the instructor.
W****-1 surprise How reliable the tests are and how it forces new additions to software to abide by previous set rules which keeps the software bug free.
W****-1 surprise Concepts were easier to catch onto than I first assumed they would.
W****-1 surprise It didn't take significantly longer, overall.
W****-1 surprise Even knowing that wrapping was coming in the future with the early test and purposely designing the simple code to handle it with the least interruption I still had to make lots of changes to actually get the wrapping case to work.
W****-1 surprise I became much more adventurous in trying different syntax and implementations knowing that I had a backstop that would alert me when I had something wrong.
W****-1 surprise Unsure about default compiler environment and options.
W****-1 surprise seems to do what it's intended, making code more bullet proof
W****-1 surprise If you have poorly written tests, you may have unjustified confidence in your code.
W**-10 surprise The shortness of the cycles.
W**-10 surprise How easy it is to make mistakes.
W**-10 surprise It surprised me how many cases and conditions could be tested for on a simple circular buffer
W**-10 surprise no surprises
W**-10 surprise Surprised that it was so simple
W**-10 surprise I was expecting it to be harder to force myself to writing the test first.
W**-10 surprise It's harder than I expected to figure out the smallest change to make.
W**-10 surprise hmm... I guess it surprised me how difficult it was to 'pass a test' with hardcoded values.
W**-10 surprise None
W**-10 surprise By taking it one step at a time, you don't necessarily think about all the ways the code could go wrong. There was at least one test where once I made the test work, I released that there was an underflow which I just fixed without realizing it.
W**-11 surprise I have no prior testing experience so I can't say I was surprised about anything.
W**-11 surprise How quickly the tests run.
W**-11 surprise Reduction in the debugging timelines.
W**-11 surprise Even when I think I am taking the smallest step, there seems to be a smaller one.
W**-11 surprise How hard it can be to produce test cases
W**-11 surprise No surprises
W**-11 surprise You don't need so much debugging because you know that the failure is in the last change you made
W**-11 surprise How simple the first implementation should be
W**-11 surprise That you are supposed to do stubby implementations just to get to the next test.
W**-11 surprise Even if it is completely different way of how to work, it seems to work very well. You can see progress, fast...
W**-11 surprise No surprise really
W**-12 surprise It was quicker than I thought it would be
W**-12 surprise How much I've forgotten about circular buffers!
W**-12 surprise The tests were quite short and easy.
W**-12 surprise Its not as scary as I had imagined
W**-12 surprise How many tests can be written to test functions and the range of testing.
W**-12 surprise Went in with an open mind. Mind == blown
W**-12 surprise How it caught some errors which I had not thought about
W**-12 surprise nothing at this moment
W**-12 surprise How many people think it is not valuable.
W**-13 surprise It forces me to think and design one functional behavior at a time
W**-13 surprise Nothing really.
W**-13 surprise My misguided understanding on TDD was that you write a fully functioning method and then write the test case. The procedure described here makes TDD more systematic.
W**-14 surprise Built-in memory testing is handy.
W**-14 surprise Development and testing very tightly coupled. Done in parallel
W**-14 surprise The unusual way of development.
W**-14 surprise I think I might like it?
W**-14 surprise The subtle way in which issues in design start getting highlighted.
W**-14 surprise that in the beginning you just hardcode the right results
W**-15 surprise Discourages thinking ahead
W**-15 surprise How well it works once you get into the flow of things.
W**-15 surprise Makes it far easier to debug code - mistakes a caught much earlier before they become the foundation of a larger code-base.
W**-15 surprise How much it organizes my thought process.
W**-15 surprise That you start off coding with known incomplete/incorrect functions & data structures, but you do that in order to get the test passing in the first place.
W**-15 surprise none
W**-15 surprise How well "slowing down to go fast" actually works
W**-15 surprise I knew it was good at regression prevention, but it was surprising to see how good tests are catching you at mistakes and stopping you from digging a deep hole
W**-15 surprise I thought I'd be more confident that I had "solved" everything but intuitively I'm really concerned that I'm missing something.
W**-15 surprise How it forces one to not think ahead.
W**-16 surprise What surprised me was that rigorously following these steps, we were able to complete the lab in it's entirety faster than those who were trying to do it with short cuts.
W**-16 surprise You can work so systematically that you can even go on with people talking all around you
W**-16 surprise The relative speed, despite the back and forth and the "cheating" to get tests to pass. Some of that felt very weird, but we finished the exercise and everything seems to be working, without extra fluff in the code.
W**-16 surprise As a group we were able to follow the process and it seemed to speed up the development process. Along with keeping the code clean.
W**-16 surprise No surprises
W**-16 surprise The test is driving the development
W**-16 surprise surprisingly simple
W**-16 surprise How small-stepped it was ^^
W**-17 surprise How much I love the sense of accomplishment that comes with green lights!
W**-17 surprise TDD appears to cause algorithms to converge on surprisingly simple solutions. E.g., Uncle Bob's bowling score example.
W**-17 surprise Since I add small features and pieces of code, it seems like I'm stuck less time thinking on what should I do. Work kind of flows.
W**-17 surprise n/a
W**-17 surprise that it is realy fun and that you can feel the spirit realy fast.
W**-17 surprise How much fun it was! It's very satisfying to follow the red-green-refactor pattern. Each one is like getting another GO flag: GO on to the next step! GO! And each one feels positive.
W**-17 surprise surprise 1106
W**-17 surprise surprise 1128
W**-17 surprise surprise 1133
W**-17 surprise surprised its friday in september
W**-17 surprise 931
W**-17 surprise It's quite difficult to revert our default behaviors. I kept forgetting to make the compiler fail BEFORE I added a new definition to the header. "I know I need to do this" pops into my head and the default flow starts.
W**-18 surprise catharsis TDD is very cathartic, You feel confidence in your design as you go.
W**-18 surprise fascinating Time consuming
W**-18 surprise Inefficient That you write implemention code at times that isn't the true implemention.
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**-18 surprise regressions structural changes may cause some detective work to get underway, clearly tracking back regressions takes practice.
W**-18 surprise speed How rapid it can be to iteratively add functionality.
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
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.
W**-18 surprise wondering The lack of forward thinking in writing code that will knowingly fail tests later.
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.
W**-19 surprise None No real surprises yet.
W**-19 surprise Progress You see the progress. If you feel like "have I thought about xyz?" you write the xyz test.
W**-19 surprise Test Tool Didnt expect some nice feedback that CPPUTEST gave me when tests failed.
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**-20 surprise failures Causing initial cases to fail.
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**-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?
W**-20 surprise iterative That decent, working code can be made iteratively, even though we started with horribly hacky code.
W**-20 surprise priority That I am worried about testing first and then development.
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**-21 surprise challenge There can be multiple test cases for small code we write.
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.
W**-21 surprise Easy to maintain TDD forces you to write unit tests before writing implementation code, refactoring of code becomes easier and faster.
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
W**-21 surprise Familiarity TDD in C++ isn't that different from doing it with other languages.
W**-21 surprise None None but I've been doing TDD for 10 years now.
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
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
W**-21 surprise short With how little implementation you can get away. And, how clean this implementation is.
W**-21 surprise straightforward It is far more straightforward than first thought.
W**-7 surprise Surprising number of people choose not to use TDD even after they have learned the technique properly. Might speculate they enjoy pain.
W**-7 surprise nothing
W**-7 surprise It is kind of easy to adopt and I can have my code tested rioght away.
W**-7 surprise We can have at the end so robust code. we can split the code in more single pieces until have the whole
W**-7 surprise It surprise me that it requires change the way to think how things are done, and that it helps to get a simpler solution
W**-7 surprise --
W**-7 surprise That you can figure out quickly if something in your code is not working correctly, and you can fix it immediately
W**-8 surprise I have used TDD before. No surprises.
W**-8 surprise Test is not in focus, the understanding of the function is.
W**-8 surprise How easily you can spiral into creating tests. Eventually you will need to come up for air :-)
W**-8 surprise How easy it is to establish flow/get in a groove.
W**-8 surprise Maybe the failing approach
W**-8 surprise how well it enables c development
W**-8 surprise That I have to go out of my way to implement things in a literal sense to pass tests but that my approach can be completely off base. So far, I don't see a large benefit. The framework is useful, but I would not be this iterative. I can go much farther and faster if I define my interface and design my complete set of tests, THEN test them one by one.
W**-8 surprise You can test and write functionality at the same time!
W**-8 surprise I am surprised at how fast you can develop even though there is additional code to write.
W**-8 surprise How difficult it was to write incorrect code in some cases.
W**-9 surprise the amount of non production code produced
W**-9 surprise How much more quickly I was able to finish my work by writing more tests, but less implementation code.
W**-9 surprise Might wind up with more lines of test code than prod code
W**-9 surprise That it is sort of "allowed" to work in such small steps :)
W**-9 surprise I read your book, so I was not so surprised.
W**-9 surprise It improves code design during development
W**-9 surprise use of temporary magic numbers in code to make codes pass (initially)
W**-9 surprise How easy it was once I got going
W**-9 surprise More effective than I first thought
W**-9 surprise It increases confidence of the code that is written.
W**-9 surprise It is surprising how fast you actually end up going.
Z****-3 surprise it was pretty fun
Z****-3 surprise The concept was a lot less complicated than I expected.
Z****-3 surprise not sure yet...
Z****-3 surprise Quality of instruction.
Z****-3 surprise I didn't think I was going to find it useful, but I do.
Z****-3 surprise mild entertainment value
Z****-3 surprise How powerful it can be in finding bugs earlier
Z****-3 surprise sorry I have none....
Z****-3 surprise Code development gets done, while test development is done
Z****-3 surprise Surprised with first making the test case fail and then writing the code to get it to pass. I would normally first generate the test cases to pass as the code is generated.
Z****-3 surprise The convenience and efficiency.
Z****-3 surprise not intuitive at first. Got ahead on typing more code than needed
Z****-3 surprise the thought process is totally different from what I'm accustom to
Z****-3 surprise Was more intuitive than I originally would have thought.
Z****-4 surprise Pretty much the same as what I liked about TDD, but it makes adding testable features very easy.
Z****-4 surprise the feedback loop was fairly quick and much easier to decipher then a traditional program.
Z****-4 surprise it was kind of fun
Z****-4 surprise The amount of test cases that are generated for a seemingly trivial implementation.
Z****-4 surprise The test framework was able to catch memory leakages and over boundary writes.
Z****-4 surprise It was much simpler than I originally thought.
Z****-4 surprise Testing and Development of code same time
Z****-4 surprise How many things are being tested
Z****-4 surprise helps to get more clear picture of the requirements
Z****-5 surprise how many steps there are
Z****-5 surprise How it finds the bugs along the way.
Z****-5 surprise Seems fragile
Z****-5 surprise It's enjoyable to see tests pass often instead of writing all the code and getting failure after failure as you fix bugs (and one final pass).
Z****-5 surprise how easy it got once you got the hang of it
Z****-5 surprise Nothing, this is not my first time looking at or using it, just the first dedicated training for it.
Z****-5 surprise No major surprises at this point.
Z****-5 surprise I wonder why this approach isn't used more often (or is it?)
Z****-5 surprise The confidence in the sturdiness of the developed code that you get when the tests complete successfully.
Z****-5 surprise Really liked the coding challenge
Z**-1 surprise adaptable It was surprisingly easy to continue doing it, once I started
Z**-1 surprise automatic It surprised me how TDD helps write tests in sort of an "automatic" way.
Z**-1 surprise impl-less I spent a lot less time thinking about implementation.
Z**-1 surprise incremental Small incremental steps actually lead to final solution.
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.
Z**-1 surprise requirements No mention of requirements or how they feed into tests.
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.
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
Z**-1 surprise Wild Explicitly de-emphasizing requirements on initial iteration cycles.
Z**-1 surprise works it works!!

Make this into a word cloud

Select text below (triple click), copy, then try one of these tag cloud generators
jasondavies word cloud generator - colorful
tagcrowd - lets you show counts