What surprised 764 people about their first TDD experience

Course code Summary selected 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
H***-1 surprise: Almost automaticly writing tests. It builds a kind of test foundation and regression testing automatically. You you may re-use a lot of tests within more complex parts, because the simple parts are already covered by tests.
H***-1 surprise: Almost automaticly writing tests. It is easier to design good tests with TDD.
H***-1 surprise: Almost automaticly writing tests. Failing the code which doesn't exist! and then write that code :-)
I**-1 surprise: Almost automaticly writing tests. It helps you on writing the test almost automatically, so that they become easily part of the process.
I**-1 surprise: Almost automaticly writing tests. It looks like a lot of testing is already taken care of with TDD
J***-1 surprise: Almost automaticly writing tests. The interface is simpler that I imagined -- getting a testing environment set up is usually frustrating
M***-1 surprise: Almost automaticly writing tests. I never do it before.
M***-2 surprise: Almost automaticly writing tests. Faster and easier than what I had expected.
M***-2 surprise: Almost automaticly writing tests. Able to complete both the unit test and the actual logic.
M***-2 surprise: Almost automaticly writing tests. Its actually enjoyable to make your test cases pass
N/A surprise: Almost automaticly writing tests. The TDD actually kept us on course.
N/A surprise: Almost automaticly writing tests. The TDD actually kept us on course.
N/A surprise: Almost automaticly writing tests. TDD may not be used to drive GUI test automatically.
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!
N/A surprise: Almost automaticly writing tests. I think the most unintuitive part of writing TDD code is not writing too much code, but I can see how it's effective as it stops you from writing untested code.
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!
W**-37 surprise: Almost automaticly writing tests. Writing tests do not require a lot of continuous effort, they come together with code.
W**-42 surprise: Almost automaticly writing tests. Small amount of code in test cases.
W**-1 surprise: Almost automaticly writing tests. I've worked with companies with unit testing before, but I haven't approached it by writing tests immediately.
Z**-1 surprise: Almost automaticly writing tests. It seems to be very easy to implement the tests.
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.
H***-1 surprise: Code is incomplete for so long. TDD will take you to think more comprehensively about coding and design.
H**-1 surprise: Code is incomplete for so long. Feels weird not having a solid implementation till later in development
H**-1 surprise: Code is incomplete for so long. How popular it is? How little awareness I had of it until about a month ago.
I**-1 surprise: Code is incomplete for so long. that you have to deliberately make the code not work for a while
I**-1 surprise: Code is incomplete for so long. The practice of faking the results of the implementation (like returning 42 from Get()). Is is as if the implementation is trying to trick the unit test.
I**-1 surprise: Code is incomplete for so long. Its kind fun.
I**-1 surprise: Code is incomplete for so long. I feel like test after may be a better fit for me; More frustrating than I expected.
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
M***-1 surprise: Code is incomplete for so long. so many corner cases should be tested
M***-1 surprise: Code is incomplete for so long. Spent more time in activity.
M**-2 surprise: Code is incomplete for so long. Nothing really as colleagues have been using it so have been partially aware of what's involved and how things are done
N/A surprise: Code is incomplete for so long. My brain immediately wants to fall back to just adding more functionality and seeing green light in the tests. Seeing incomplete code and testing it is different.
N/A surprise: Code is incomplete for so long. The small incremental tests do help make sure your code only does what its supposed to.
N/A surprise: Code is incomplete for so long. Implementing a circular buffer, it did not function as a circular buffer until ~75% of the way through the tests.
N/A surprise: Code is incomplete for so long. I was surprised about writing code foremost to pass the test instead of starting with a basic implementation.
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.
N/A surprise: Code is incomplete for so long. To really implement only what is needed at that time and keeping it super simple, not getting ahead of yourself.
N/A surprise: Code is incomplete for so long. Not expected to keep the code incomplete for so long.
N/A surprise: Code is incomplete for so long. It will take time getting used to writing "just enough" code and not overthinking the implementation for the current test. (I did add comments in the code for incomplete features/functionality.)
N/A surprise: Code is incomplete for so long. Code takes a lot longer to flesh out this way
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.
H**-1 surprise: Easier than I thought it would be. Writing tests seems easy.
M***-1 surprise: Easier than I thought it would be. Easy to add test cases to debug and confirm the functionality without creating other functions/modules to interact.
M***-1 surprise: Easier than I thought it would be. I was surprised how fun it was. Following the rules of TDD creates a fun challenge, and the red, green feedback makes it feel a little like a puzzle game.
M***-1 surprise: Easier than I thought it would be. Ease of use.
M**-2 surprise: Easier than I thought it would be. It flowed more smoothy than I expected.
M**-2 surprise: Easier than I thought it would be. I feel like the process of development in this way was easier than I had anticipated.
M**-2 surprise: Easier than I thought it would be. I feel like the process of development in this way was easier than I had anticipated.
M**-2 surprise: Easier than I thought it would be. no surprises so far
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
N/A surprise: Easier than I thought it would be. Was definitely easy to get started!
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.
W**-37 surprise: Easier than I thought it would be. I didn't seem to have any difficulty fighting the TDD process. It was easy to focus on writing a test, failing, then making it pass and moving to the next one.
W**-37 surprise: Easier than I thought it would be. The simplicity of the tests (at least for this example!).
W**-39 surprise: Easier than I thought it would be. That I'm able to pick it up somewhat quickly, despite thinking that I had a huge mental roadblock for implementing this. I just needed the dedicated time and space to guide me.
W**-40 surprise: Easier than I thought it would be. that every time a test passed, we found ourselves starting with the question "Shall we write another test?"
W**-40 surprise: Easier than I thought it would be. It is actually not annoying as it seems to write tests while developing.
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
H***-1 surprise: I spent less time thinking of implementation. Once we find all the possible test sets its very easy to code!!
H***-1 surprise: I spent less time thinking of implementation. Less time spent in structuring of code
H***-1 surprise: I spent less time thinking of implementation. boundary/corner cases are covered easily.
H**-1 surprise: I spent less time thinking of implementation. I was surprised how effective I was coding with this method.
H**-1 surprise: I spent less time thinking of implementation. I could start coding before fully thinking about how to do the implementation.
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.
M***-1 surprise: I spent less time thinking of implementation. I took me less time to finish the CircularBuffer design.
M***-1 surprise: I spent less time thinking of implementation. The mindset of TDD is to solve problem at one time, do not consider too much at this moment. I think is a good way when I get stuck in some situation. consider too much and can't move on!
M***-1 surprise: I spent less time thinking of implementation. It helps us to step by step to figure out the requirement and make previous progress still working fine.
M***-1 surprise: I spent less time thinking of implementation. It helps us to step by step to figure out the requirement and make previous progress still working fine.
M***-2 surprise: I spent less time thinking of implementation. Less time required for implementation
M***-2 surprise: I spent less time thinking of implementation. Ability to detect the failures and change the code. Iterative approach every time it takes to cover regressions.
M***-1 surprise: I spent less time thinking of implementation. The most surprising aspect of TDD is the minimal implementation (saving time from writing unnecessary code).
M***-1 surprise: I spent less time thinking of implementation. The most surprising aspect of TDD is the minimal implementation (saving time from writing unnecessary code).
M***-1 surprise: I spent less time thinking of implementation. I thought there would be more design up front
M***-1 surprise: I spent less time thinking of implementation. It was very stress free! I didn't have to worry about edge cases that I knew we didn't take care of because I knew that as more tests were being added they would force me to handle this.
N/A surprise: I spent less time thinking of implementation. Was easy to get feedback right away and broke the problem up into smaller problems
N/A surprise: I spent less time thinking of implementation. Was easy to get feedback right away and broke the problem up into smaller problems
N/A surprise: I spent less time thinking of implementation. When the tests are already developed, we found it took less time to implement our code.
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
N/A surprise: I spent less time thinking of implementation. TDD was easier than I expected, with less overthinking solutions.
N/A surprise: I spent less time thinking of implementation. Way more strait forward once you have tests
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
W**-37 surprise: I spent less time thinking of implementation. Most surprising is that I often start by thinking of edge cases and worrying about them from the start. This time I didn't think about the edge cases until I was writing the test for it.
W**-38 surprise: I spent less time thinking of implementation. Starting not focusing on the implementation of the system but the core interaction of the system
W**-38 surprise: I spent less time thinking of implementation. I was surprised or learned how to write really basic units tests that I can change later as I made progress in the code. Small incremental tests really helped with the problem solving.
W**-38 surprise: I spent less time thinking of implementation. I was surprised or learned how to write really basic units tests that I can change later as I made progress in the code. Small incremental tests really helped with the problem solving.
W**-39 surprise: I spent less time thinking of implementation. Less time thinking of implementation - This might be too soon to say but I hope it's true!
W**-40 surprise: I spent less time thinking of implementation. Incremental building of code
W**-40 surprise: I spent less time thinking of implementation. More easy to write functions code
W**-40 surprise: I spent less time thinking of implementation. less time thinking about the implementation
W**-41 surprise: I spent less time thinking of implementation. It helps a lot with designing the implementation when you only have to write/think about a small part of it at a time
Z**-1 surprise: I spent less time thinking of implementation. It is fast an easy
Z**-1 surprise: I spent less time thinking of implementation. It's awesome how easy it is to do simple tests and have well-structured code working this way.
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
I**-1 surprise: None. I was surprised by how quick the implementation of the functions be tested was progressing
J***-1 surprise: None. It seems to be a very thorough way of making your code robust
M***-1 surprise: None. The concept is ease but thinking of implementation take more.
M***-2 surprise: None. simpler approach
M***-2 surprise: None. simpler approach
M***-2 surprise: None. still in surprise
M***-2 surprise: None. No surprises here!
M***-2 surprise: None. Nothing
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.
W**-37 surprise: None. Making the function fail first
W**-38 surprise: None. The immense DOPAMINE RUSH from refactoring code.
W**-40 surprise: None. we spent an hour writing a buffer and didn't get to writing the actual buffer object
W**-40 surprise: None. It's very effective from the beginning.
W**-40 surprise: None. It's very effective from the beginning.
W**-40 surprise: None. It's very effective from the beginning.
W**-40 surprise: None. It's very effective from the beginning.
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.
E***-1 surprise: Nothing. I was slightly familiar with TDD, so not completely surprised (yet) ;)
H***-1 surprise: Nothing. None
H***-1 surprise: Nothing. -NA-
H**-1 surprise: Nothing. No surprises.
H**-1 surprise: Nothing. No surprises.
I**-1 surprise: Nothing. works as expected
I**-1 surprise: Nothing. N/A...
M***-1 surprise: Nothing. It created some good coding concepts for engineers to have good coding behaviors.
M***-2 surprise: Nothing. Nothing
M***-1 surprise: Nothing. Nothing
M**-2 surprise: Nothing. Nothing.
N/A surprise: Nothing. Nothing surprised me as I have done this type of coding at Pivotal.
N/A surprise: Nothing. I had TDD explained to me once by a senior developer. Similar to the process explained here
N/A surprise: Nothing. No surprises no far. I don't know if I'm doing TDD right.
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.
N/A surprise: Nothing. I'm a young enough engineer that test-driven development has been more or less encouraged since day 1 of my training & career. What surprises me most is that not everyone likes it :)
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
W**-37 surprise: Nothing. No surprises so far.
W**-38 surprise: Nothing. I've done TDD for a while, so this was not a surprise.
W**-38 surprise: Nothing. Not much really
W**-38 surprise: Nothing. No surprises
W**-40 surprise: Nothing. nothing so far
W**-41 surprise: Nothing. There is no surprise for me.
W**-41 surprise: Nothing. ı surprised about how much friendly is james :) Salute that man!
W**-1 surprise: Nothing. Business as usual.
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
H***-1 surprise: Other. Finding earlier tests that started to fail after refactor. Neat!
M***-1 surprise: Other. The want to write multiple tests before I write any code.
M***-1 surprise: Other. TDD gives me feedback right away when i make mistakes.
N/A surprise: Other. I am intrigued at the implementation process the follows TDD
N/A surprise: Other. Gathertown is a neat platform
N/A surprise: Other. Gathertown is a neat platform
N/A surprise: Other. When I would break an early simple test with a small change
N/A surprise: Other. Allows for closer inspection of the foundational elements of the code. Things that may get rushed through because it is "basic".
N/A surprise: Other. No surprises. The class was straight forward. Maybe changing the IDE interface to something more familiar such as Microsoft VS's layout would help.
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.
W**-38 surprise: Other. So much easier to pickup syntax when working in a pair with TDD! The tests helped me know how to write the code
W**-38 surprise: Other. So much easier to pickup syntax when working in a pair with TDD! The tests helped me know how to write the code
W**-38 surprise: Other. So much easier to pickup syntax when working in a pair with TDD! The tests helped me know how to write the code
W**-38 surprise: Other. So much easier to pickup syntax when working in a pair with TDD! The tests helped me know how to write the code
W**-38 surprise: Other. The immense DOPAMINE RUSH from refactoring code.
W**-40 surprise: Other. How the tests shaped the design of my code and kept it simple.
W**-41 surprise: Other. This is more for pair programming, but I like that there are discussions with my partner on the implementation, and I can see other possible solutions.
W**-41 surprise: Other. Dynamic memory error messages were clear and useful. Constructor one was not.
W**-1 surprise: Other. I was surprised to realize the usefulness of how a thorough test suite can provide a good means of regression testing.
Z**-1 surprise: Other. The TDD strategy makes the .h, .c and TEST.cpp very clean and organised. It improves readability.
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
H***-1 surprise: TDD is different than I thought. Its effectiveness .. Like never look back for that particular usecase again once passed
H***-1 surprise: TDD is different than I thought. -Felt exciting to write a failed test, and then fix it.
H**-1 surprise: TDD is different than I thought. I was surprised that it forced me to remove/eliminate irrelevant code.
I**-1 surprise: TDD is different than I thought. That the tests are written before writing the code.
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
M***-1 surprise: TDD is different than I thought. It looks simple, but actually reliable when it comes to testing code.
M***-1 surprise: TDD is different than I thought. It will take some time to think about the test case. And test code steps by steps.
M***-1 surprise: TDD is different than I thought. The concept is ease but thinking of implementation take more time.
M***-1 surprise: TDD is different than I thought. Different thought. I never consider the test case before I really program the production code.
M***-2 surprise: TDD is different than I thought. It was a interactive session, I forgot some corner cases.
M***-2 surprise: TDD is different than I thought. TDD is different than I thought
M***-2 surprise: TDD is different than I thought. Thinking of new testcases came sooner when doing ding along side coding.
M***-2 surprise: TDD is different than I thought. still in surprises
M***-1 surprise: TDD is different than I thought. I thought that TDD would involve writing all of the tests for a given feature/module, and then writing the code. I did not expect that the tests would be written simultaneously.
M***-1 surprise: TDD is different than I thought. quick feedback
M**-2 surprise: TDD is different than I thought. It is a satisfying process.
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.
N/A surprise: TDD is different than I thought. My brain and fingers want to jump ahead to implementation details. It's hard to slow down and work piece by piece!
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.
W**-40 surprise: TDD is different than I thought. I needs some rethinking, but if you are willing to change its an instant improvement.
W**-40 surprise: TDD is different than I thought. I write different sorts of test than I would with test-later. I'd expect to write about the same tests, just at a different point in time; but TDD tests are usually much smaller and narrow-focused
W**-41 surprise: TDD is different than I thought. It doesn't seem as boring as I expected it to be at first.
W**-41 surprise: TDD is different than I thought. tdd is a new world for me, wingman is taking us to the this new world, he is a good pilot (:
W**-41 surprise: TDD is different than I thought. This platform is pretty much interactive to work collaboratively.
W**-42 surprise: TDD is different than I thought. How "noobish" and out of depth i feel ( might be a good sign )
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
E***-1 surprise: TDD was easier than I thought. Make tests fail on purpose first
H***-1 surprise: TDD was easier than I thought. TDD is easier to start with than the complexities I earlier thought of
H***-1 surprise: TDD was easier than I thought. All I have to remember is to write tests to the smallest piece of code I plan to add.
H**-1 surprise: TDD was easier than I thought. Writing the tests is an easier process than I thought. I figured you more work to implement the tests into your design.
H**-1 surprise: TDD was easier than I thought. Writing the tests is an easier process than I thought. I figured you more work to implement the tests into your design.
H**-1 surprise: TDD was easier than I thought. Writing the tests is an easier process than I thought. I figured you more work to implement the tests into your design.
H**-1 surprise: TDD was easier than I thought. Writing the tests is an easier process than I thought. I figured you more work to implement the tests into your design.
I**-1 surprise: TDD was easier than I thought. It wasn't that bad.
J***-1 surprise: TDD was easier than I thought. It's pretty easy and fun :)
M***-1 surprise: TDD was easier than I thought. different mindset with legacy programmer.
M***-2 surprise: TDD was easier than I thought. Even a simple test cases can capture critical bugs
N/A surprise: TDD was easier than I thought. It is easy that I though and I can add more features easily.
M**-1 surprise: TDD was easier than I thought. It was relatively easy.
M**-2 surprise: TDD was easier than I thought. How easy and simple it is.
N/A surprise: TDD was easier than I thought. Interface was different. Very simple to navigate
N/A surprise: TDD was easier than I thought. It is easy if the tests are already laid out
N/A surprise: TDD was easier than I thought. It was not to hard to implement the practice.
N/A surprise: TDD was easier than I thought. At how simple it is. Your approach matters and will confuse you at the same time.
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.
W**-37 surprise: TDD was easier than I thought. How easy it feels after learning curve/
W**-37 surprise: TDD was easier than I thought. - Seems easier to get the hang of/integrate into my workflow than I originally though
W**-39 surprise: TDD was easier than I thought. It's super easy to implement.
W**-40 surprise: TDD was easier than I thought. How much easier it makes it to break down a problem.
W**-40 surprise: TDD was easier than I thought. -------
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.
H***-1 surprise: That it works! It is really finding the bugs early
H***-1 surprise: That it works! As we progressed, we changed our code. But the previous tests gave me confidence that I'm not breaking something that was working before. Even if it is breaking it, I come to know about it and fix it.
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 is light-weighted and easy to perform
M***-1 surprise: That it works! None
M***-1 surprise: That it works! None
M***-1 surprise: That it works! It works well in this module 1
M**-1 surprise: That it works! It was easier than I thought
M**-2 surprise: That it works! TDD looks at all the boundary conditions and fully tests them!
N***-2 surprise: That it works! While implementing test cases in my project, I observed that, the testcases were executing from bottom to top, that really surprised me.
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.
W**-37 surprise: That it works! the advantages for demonstrate to the customer, low level requirements through unit tests.
W**-40 surprise: That it works! Hard to set up good coverage but in the end, the tested code works
W**-40 surprise: That it works! how easy is make mistakes.
W**-42 surprise: That it works! It's very satisfying to see the code do what you've "predicted" it will do
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! small steps: first make compiler fail, make linker fail, let test fail, make test succeed.
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.
H***-1 surprise: The small steps! It tests and develops at the same time.
H***-1 surprise: The small steps! Initial steps are tiny but the more tests we have the more time it requires to fix non-passing tests
H***-1 surprise: The small steps! it forces me design, implement and test one method at a time, without TDD, i would have implemented all methods in one shot without thinking about the design/usecases/risks in depth
H**-1 surprise: The small steps! If you are in an environment enabled for TDD, it is really simple to begin using TDD
H**-1 surprise: The small steps! It started to make some sense and use of the test.
I**-1 surprise: The small steps! surprised as it is hard to think about the tests for the simple code
I**-1 surprise: The small steps! The small steps and iterative development
I**-1 surprise: The small steps! How simple it is to write a test
I**-1 surprise: The small steps! How simple it is to write a test
I**-1 surprise: The small steps! I'm surprised that we go very slow in terms of getting code implemented and tested. THis is a good thing though
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***-1 surprise: The small steps! Little tiny steps, and writing code that ignores what I want the function to do
L****-1 surprise: The small steps! Teeny tiny iteration
M***-1 surprise: The small steps! We learn a lot!
M***-2 surprise: The small steps! Some of the things I do it in my day-to-day job
M***-2 surprise: The small steps! UI is awesome. It surprised me.
M***-2 surprise: The small steps! Small steps in code writing makes easy to find the bugs at early stage.
M***-2 surprise: The small steps! there are so many small test cases which we generally skip during our testing
M***-2 surprise: The small steps! Small & simple steps
M***-2 surprise: The small steps! Small & simple steps
M***-2 surprise: The small steps! Small & simple steps
M***-1 surprise: The small steps! nothing really surprised me as I had a decent amount of knowledge about tdd coming in. I guess maybe that is is so micro stepped.
M***-1 surprise: The small steps! TDD keeps you focused while designing without overthinking your approach.
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.
M**-2 surprise: The small steps! It ensures that we are going to find bugs before we introduce them but the amount of bugs we will find are linked to the quality of tests we create.
M**-2 surprise: The small steps! Harder to stop myself from fully implementing functions than I expected.
M**-2 surprise: The small steps! Increments are maybe smaller than expected.
M**-2 surprise: The small steps! It is great the fact that this can be used to catch bugs in advance, contrary to other development cycles where testing is done after the development.
N/A surprise: The small steps! The very small increments in the process of TDD
N/A surprise: The small steps! I like doing things in small steps.
N/A surprise: The small steps! Writing tests knowing that it will fail
N/A surprise: The small steps! How it starts with the simplest of tests and then starts getting built up.
N/A surprise: The small steps! The small steps it takes to build something big, and how easy it is to manage.
N/A surprise: The small steps! TDD is what make out of it. Sure work places can make you create test code for a program but if you make the test code just to pass, is it really testing code?
N/A surprise: The small steps! Taking very small steps at each compile was surprising but effective.
N/A surprise: The small steps! There are a lot of smaller steps involved and you constantly have to be building the code to check for bugs
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.
N/A surprise: The small steps! The amount of things tested in each test was smaller than anticipated
N/A surprise: The small steps! I was surprised at the speed of iteration cycles.
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**-37 surprise: The small steps! Focus on getting things done once at a time Compile error->Linker error->Test error Seems like something I try to do in my head anyway but the structure could be really useful
W**-37 surprise: The small steps! Almost each step needs to be tested.. It is easy to forget that often..
W**-37 surprise: The small steps! I always thought I worked in small steps, to begin with. These micro steps made it easier to work my way through this problem.
W**-37 surprise: The small steps! Usually I want to jump into developing whole solution - TDD makes you think about solution more before writing everything.
W**-37 surprise: The small steps! I liked the small cycles.
W**-38 surprise: The small steps! How small the steps can be.
W**-38 surprise: The small steps! How difficult it was to come up with minimal solutions to minimal tests
W**-38 surprise: The small steps! Surprised at how small of a change we should make to our code in order to pass a test.
W**-38 surprise: The small steps! Surprised at how small of a change we should make to our code in order to pass a test.
W**-39 surprise: The small steps! It has always surprised me how short steps empowers us
W**-39 surprise: The small steps! Every step is very small
W**-39 surprise: The small steps! development increment process
W**-40 surprise: The small steps! I enjoyed how incremental it felt and how it broke down everything into smaller steps.
W**-41 surprise: The small steps! It is testing basic steps that you never thought of testing.
W**-41 surprise: The small steps! At any given point, for the functionality implemented, it is guaranteed that it is completely tested
W**-41 surprise: The small steps! Easy to work with small steps.
W**-41 surprise: The small steps! You can get positive feedback on your implementation quickly and traceably.
W**-42 surprise: The small steps! Applying TDD shows that every piece of code you write contains so many choices and consequences
W**-1 surprise: The small steps! I was surprised at the value of breaking the implementation into smaller steps and iteratively testing to get to the final implementation.
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.