What surprised 899 people about their first TDD experience

Summary selected Impressions
surprise: #compiles the amount of compilations/builds
surprise: #compiles the amount of compilations/builds
surprise: 851 surprise 851
surprise: adaptable It was surprisingly easy to continue doing it, once I started
surprise: Almost automaticly writing tests. How quickly I was able to adapt to the sequence
surprise: Almost automaticly writing tests. Writes the requirements too! When you think of the test, you also think of the requirements
surprise: Almost automaticly writing tests. Almost automatically writing the tests
surprise: Almost automaticly writing tests. Almost automatically writing the tests
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.
surprise: Almost automaticly writing tests. It is easier to design good tests with TDD.
surprise: Almost automaticly writing tests. Failing the code which doesn't exist! and then write that code :-)
surprise: Almost automaticly writing tests. When the code is finished lots of testing is already done, which helps with the classic problem of the last 10% of work taking 90% of the time
surprise: Almost automaticly writing tests. Not too much, somewhat familiar with.
surprise: Almost automaticly writing tests. It helps you on writing the test almost automatically, so that they become easily part of the process.
surprise: Almost automaticly writing tests. It looks like a lot of testing is already taken care of with TDD
surprise: Almost automaticly writing tests. The interface is simpler that I imagined -- getting a testing environment set up is usually frustrating
surprise: Almost automaticly writing tests. I never do it before.
surprise: Almost automaticly writing tests. Faster and easier than what I had expected.
surprise: Almost automaticly writing tests. Able to complete both the unit test and the actual logic.
surprise: Almost automaticly writing tests. Its actually enjoyable to make your test cases pass
surprise: Almost automaticly writing tests. The TDD actually kept us on course.
surprise: Almost automaticly writing tests. The TDD actually kept us on course.
surprise: Almost automaticly writing tests. TDD may not be used to drive GUI test automatically.
surprise: Almost automaticly writing tests. Despite the strange workflow, I ended up with an extremely comprehensive suite of tests
surprise: Almost automaticly writing tests. the number of tests created
surprise: Almost automaticly writing tests. the number of tests created
surprise: Almost automaticly writing tests. the number of tests created
surprise: Almost automaticly writing tests. With using TDD you nearly get the tests for free
surprise: Almost automaticly writing tests. More fun than expected!
surprise: Almost automaticly writing tests. Ease of use. How quickly new tests were built, new production capability added!
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.
surprise: Almost automaticly writing tests. Easy to use and rapidly expandable test framework that helps in the actual implemenatation in an iterative way.
surprise: Almost automaticly writing tests. Once you get the flow of the process it clicks and to development process flows quickly
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
surprise: Almost automaticly writing tests. That making a known insufficient implementation actually reveals that the tests are not yet good enough
surprise: Almost automaticly writing tests. I can write unit test and think like a end user
surprise: Almost automaticly writing tests. we have tests now
surprise: Almost automaticly writing tests. How it helps to keep the implementation simple and composable.
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.
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
surprise: Almost automaticly writing tests. Tests are written quite fast.
surprise: Almost automaticly writing tests. The small test steps and it is helpful to cover all the edge cases.
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!
surprise: Almost automaticly writing tests. Writing tests do not require a lot of continuous effort, they come together with code.
surprise: Almost automaticly writing tests. Small amount of code in test cases.
surprise: Almost automaticly writing tests. I was surprised by how TDD can lead to more modular and decoupled code.
surprise: Almost automaticly writing tests. Doubts about undocumented details became safely bounded. Having a test harness, changes are controlled. By starting to think on tests, the implementation becomes clearer before writing any code.
surprise: Almost automaticly writing tests. I've worked with companies with unit testing before, but I haven't approached it by writing tests immediately.
surprise: Almost automaticly writing tests. It seems to be very easy to implement the tests.
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.
surprise: automatic It surprised me how TDD helps write tests in sort of an "automatic" way.
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.
surprise: bits it might be easier to build up little bits of correct code than to try and develop all of the functionality initially
surprise: boring how boring it was
surprise: Bug-resist It definitely has potential to do great in catching bugs early
surprise: bugs How many unexpected bugs I write.
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.
surprise: catharsis TDD is very cathartic, You feel confidence in your design as you go.
surprise: challenge There can be multiple test cases for small code we write.
surprise: Challenging The difficulty I had in keeping to the smallest change possible that makes the code work.
surprise: clear clear concepts, easy to use.
surprise: Code is incomplete for so long. Fake it until you make it seems silly, but this exercise helped show the benefits.
surprise: Code is incomplete for so long. Start from very small.
surprise: Code is incomplete for so long. It is alright to write dummy code and placeholders for future tests.
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
surprise: Code is incomplete for so long. The small increments are very very small in some cases.
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.
surprise: Code is incomplete for so long. Implementing things wrong
surprise: Code is incomplete for so long. Code is incomplete for so long it makes me want to jump ahead!
surprise: Code is incomplete for so long. the reverse approach compared to the usual one
surprise: Code is incomplete for so long. Clean implementation step by step and easy refactoring
surprise: Code is incomplete for so long. code might not get complete if test suite is not complete
surprise: Code is incomplete for so long. How much "faking" it involves initially.
surprise: Code is incomplete for so long. you can have a lot of green passing test but code is incomplete.
surprise: Code is incomplete for so long. So much more time is spent writing tests than the logical code.
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.
surprise: Code is incomplete for so long. TDD will take you to think more comprehensively about coding and design.
surprise: Code is incomplete for so long. Feels weird not having a solid implementation till later in development
surprise: Code is incomplete for so long. How popular it is? How little awareness I had of it until about a month ago.
surprise: Code is incomplete for so long. multiple steps to check compile, link, fail and pass is very thorough but was not expected
surprise: Code is incomplete for so long. that you have to deliberately make the code not work for a while
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.
surprise: Code is incomplete for so long. Its kind fun.
surprise: Code is incomplete for so long. I feel like test after may be a better fit for me; More frustrating than I expected.
surprise: Code is incomplete for so long. just do what needs to pass.. even if to be changed in next step
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.
surprise: Code is incomplete for so long. I didn't realize that I'd start off with more tests than design in TDD.
surprise: Code is incomplete for so long. The code for the first few tests are sparse
surprise: Code is incomplete for so long. so many corner cases should be tested
surprise: Code is incomplete for so long. Spent more time in activity.
surprise: Code is incomplete for so long. Being able to write tests with hard-coded return values for so long before being guided into implementation considerations.
surprise: Code is incomplete for so long. I may like to skip some steps but I may be wrong.
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
surprise: Code is incomplete for so long. I'm surprised at how long it takes to create bare-bone tests without the source code implementation. In addition, that it works despite not having fully fleshed out code.
surprise: Code is incomplete for so long. Fake it til you make it is such an interesting concept.
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.
surprise: Code is incomplete for so long. The small incremental tests do help make sure your code only does what its supposed to.
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.
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.
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.
surprise: Code is incomplete for so long. Takes a long time to get to code that's doing what it's supposed to
surprise: Code is incomplete for so long. Hard-coding pushes implementation out
surprise: Code is incomplete for so long. Procrastination is good :P
surprise: Code is incomplete for so long. I'm surprised by just how intensely I have to modify my thinking even though the end result 'should' be the same.
surprise: Code is incomplete for so long. moving forwards quickly, maybe onto the next test, leaving in faked/hard-coded values in as part of the previous test
surprise: Code is incomplete for so long. It works, it forces one to think in small steps and clearer challenges, fast feedback feels good
surprise: Code is incomplete for so long. in larger components/classes, tiny steps like this are feeling clumsy..
surprise: Code is incomplete for so long. We are starting by "dummy code", that turns into final implementation when we have exhaustive tests.
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.
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.
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.
surprise: Code is incomplete for so long. Not expected to keep the code incomplete for so long.
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.)
surprise: Code is incomplete for so long. Code takes a lot longer to flesh out this way
surprise: Code is incomplete for so long. too small steps to achieve a running functionality
surprise: Code is incomplete for so long. Weak design probably until you have covered all the scenarios.
surprise: Code is incomplete for so long. Writing code that is incomplete is OK.
surprise: Code is incomplete for so long. the feedback is nice. would need more practice to say more
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.
surprise: Code is incomplete for so long. The step-wise fashion of fail/pass.
surprise: Code is incomplete for so long. Difficult to go "one step at a time".
surprise: Code is incomplete for so long. How long it takes to get a working product
surprise: Code is incomplete for so long. Found I needed to hold myself back from jumping ahead to a full featured design.
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.
surprise: Code is incomplete for so long. You make code not completly fonctionnal and you test it.
surprise: Code is incomplete for so long. Faking out results in the beginning as opposed to implementing minimal functionality.
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.
surprise: Code is incomplete for so long. Keep myself of writing what I think is right This is actually fun to write test first
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.
surprise: Confidence This helps to capture bugs earlier during the development itself. The measure of confidence I get when I write tests is amazing.
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.
surprise: Considering_REQ It makes me think deeply about the requirement/design before the implementation.
surprise: convenient A complex problem is broken down in manageable pieces.
surprise: CppUtest Rox! CppUtest continues to be awesome around memory corruption and leaks!
surprise: design You can design the coding and testing then implement them
surprise: developement Feels like developement, not test
surprise: development support Some solutions in the algorithm was already implemented by implementing and solving a smaller part of the problem.
surprise: difficulty Everyone seemed to struggle a bit, even ppl who've had experience w/testing.
surprise: disruptive How different it is, when you're actually doing it, from almost anything I have been taught.
surprise: document A uniform way to build and document test cases.
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.
surprise: Easier than I thought it would be. The ease of use of the tools.
surprise: Easier than I thought it would be. Automatic detection of memory leaks.
surprise: Easier than I thought it would be. Is surprisiling effective given the amount of test code one needs to write.
surprise: Easier than I thought it would be. It felt more iterative and less tedious than I expected.
surprise: Easier than I thought it would be. How quick it can be once initial setup is done.
surprise: Easier than I thought it would be. Writing tests seems easy.
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.
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.
surprise: Easier than I thought it would be. Ease of use.
surprise: Easier than I thought it would be. Having quick feedback loop of running unit tests is important. Our configuration takes several steps to be able to run tests on target arch.
surprise: Easier than I thought it would be. It flowed more smoothy than I expected.
surprise: Easier than I thought it would be. I feel like the process of development in this way was easier than I had anticipated.
surprise: Easier than I thought it would be. I feel like the process of development in this way was easier than I had anticipated.
surprise: Easier than I thought it would be. no surprises so far
surprise: Easier than I thought it would be. How well it can create a testing system based off minor tests being developed at each step of the way. No need for complicated test cases and thought processes.
surprise: Easier than I thought it would be. The few cases where the test already passed, I didn't need write anything additional
surprise: Easier than I thought it would be. With my usual test after approach I had to get "over the hump" at one point, that is the point when multiple different tests start to fail. Forcing myself to do smaller steps might make it easier.
surprise: Easier than I thought it would be. Was definitely easy to get started!
surprise: Easier than I thought it would be. easy to use
surprise: Easier than I thought it would be. Easier than expected, most of the work is in initial test design (what, when, how)
surprise: Easier than I thought it would be. It is fun
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.
surprise: Easier than I thought it would be. Surprised how easy it was to setup.
surprise: Easier than I thought it would be. It's easier than I expected.
surprise: Easier than I thought it would be. you can start even before production code is written
surprise: Easier than I thought it would be. Implementing the test in the code is easier than I expected.
surprise: Easier than I thought it would be. I did not knew TDD in C was possible.
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.
surprise: Easier than I thought it would be. The simplicity of the tests (at least for this example!).
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.
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?"
surprise: Easier than I thought it would be. It is actually not annoying as it seems to write tests while developing.
surprise: easiness It's easier than I thought. It can be automatic.
surprise: easy Had no expectations, but it has been easier to follow than what I anticipated
surprise: Easy Easy to make TEST code
surprise: Easy Easy Concepts and Applications
surprise: easy Easy to understand the concept.
surprise: easy easy to build/test from the get go. Perhaps not very surprising after all but anyways :D
surprise: easy prevence How it is easy to prevent silly and hidden bugs.
surprise: Easy to maintain TDD forces you to write unit tests before writing implementation code, refactoring of code becomes easier and faster.
surprise: easy to use Not as difficult as expected.
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
surprise: Efficiency Easy Approach to test the functions
surprise: emergent the way a working and complete code-base appears out of thin-air
surprise: failure That we are supposed to make it fail first
surprise: failures Causing initial cases to fail.
surprise: fake it is OK to 'fake it 'till you make it'
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.
surprise: Familiarity TDD in C++ isn't that different from doing it with other languages.
surprise: fascinating Time consuming
surprise: Flexibility The CppUTest infrastructure seems a good mix of formality and flexibility.
surprise: flow of coding The flow of coding with TDD seems reasonable.
surprise: force-fail Forcing failures as an effective technique.
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.
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.
surprise: Fun More enjoyable than I thought
surprise: fun I found it a lot more fun than what I expected.
surprise: fun it did make writing code more interactive since we saw the result almost immediately
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)
surprise: Good Code I surprised TDD could produce good code because it makes me think how to prevent bugs much.
surprise: Good to learn Have to think all possible test cases for a system.
surprise: great Testing API very well and clarify factors for these APIs
surprise: handy It's easy and handy
surprise: Hard How hard it is to stop yourself from not adding more functionality than needed. Easy to go too far too early
surprise: Hard A bit surprised how hard it is to NOT add more code than needed.
surprise: hard-coding It feels weird hard coding obviously incorrect code. How do you make sure that none of the hard coded things linger?
surprise: healthy TDD is a healthy practice as the developer need not concentrate much while developing software
surprise: helpful - Help developer think a lot about what they will code - Saving debug time
surprise: Helps development TDD actually helps a lot with the thinking during development
surprise: I can do this Step by step breaking bigger things up into smaller chunks
surprise: I spent less time thinking of implementation. New way of thinking, no need to predict upcoming changes.
surprise: I spent less time thinking of implementation. Writing the test and implementation together felt very straight forward rather than backwards.
surprise: I spent less time thinking of implementation. Infinite tests
surprise: I spent less time thinking of implementation. No designing is required.
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.
surprise: I spent less time thinking of implementation. Helps into designing the implementation.
surprise: I spent less time thinking of implementation. I spent less time thinking of implementation
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
surprise: I spent less time thinking of implementation. It makes development a lot easier. Do the simplest thing that is solving one problem at a time.
surprise: I spent less time thinking of implementation. I spent more time thinking about the test than on the implementation. But I spent so much time thinking about the easier way to make my code pass the test without modifying it too much
surprise: I spent less time thinking of implementation. Once we find all the possible test sets its very easy to code!!
surprise: I spent less time thinking of implementation. Less time spent in structuring of code
surprise: I spent less time thinking of implementation. boundary/corner cases are covered easily.
surprise: I spent less time thinking of implementation. I was surprised how effective I was coding with this method.
surprise: I spent less time thinking of implementation. I could start coding before fully thinking about how to do the implementation.
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.
surprise: I spent less time thinking of implementation. I took me less time to finish the CircularBuffer design.
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!
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.
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.
surprise: I spent less time thinking of implementation. Less time required for implementation
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.
surprise: I spent less time thinking of implementation. The most surprising aspect of TDD is the minimal implementation (saving time from writing unnecessary code).
surprise: I spent less time thinking of implementation. The most surprising aspect of TDD is the minimal implementation (saving time from writing unnecessary code).
surprise: I spent less time thinking of implementation. I thought there would be more design up front
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.
surprise: I spent less time thinking of implementation. No need to think about approach, its derived from behavior.
surprise: I spent less time thinking of implementation. Was easy to get feedback right away and broke the problem up into smaller problems
surprise: I spent less time thinking of implementation. Was easy to get feedback right away and broke the problem up into smaller problems
surprise: I spent less time thinking of implementation. When the tests are already developed, we found it took less time to implement our code.
surprise: I spent less time thinking of implementation. It seems tests are too granular, however I can converge on working solution rather quickly.
surprise: I spent less time thinking of implementation. Having the set of test predefined made the implementation of the code much quicker
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
surprise: I spent less time thinking of implementation. Eases design decision, but again concerned about coming up with tests.
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
surprise: I spent less time thinking of implementation. Not thinking ahead is harder than I thought.
surprise: I spent less time thinking of implementation. You spend less time thinking of implementation which might be good.
surprise: I spent less time thinking of implementation. You spend less time thinking of implementation which might be good.
surprise: I spent less time thinking of implementation. You can decide when it is time to do the "proper" implementation, even if there is no test to drive it, only guide it.
surprise: I spent less time thinking of implementation. You can decide when it is time to do the "proper" implementation, even if there is no test to drive it, only guide it.
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
surprise: I spent less time thinking of implementation. If it works don't touch it unless a test fails :)
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.
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
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
surprise: I spent less time thinking of implementation. The "do the most simple thing" mantra actually works!
surprise: I spent less time thinking of implementation. - spend less time worrying about implementation. TDD lets the test drive the implementation
surprise: I spent less time thinking of implementation. TDD was easier than I expected, with less overthinking solutions.
surprise: I spent less time thinking of implementation. Way more strait forward once you have tests
surprise: I spent less time thinking of implementation. complete different way to develop software, but I like it
surprise: I spent less time thinking of implementation. How quickly you can get multiple tests completed and running
surprise: I spent less time thinking of implementation. How easy it is to build a working solution with making simple problems (tests).
surprise: I spent less time thinking of implementation. Change the way of developing code
surprise: I spent less time thinking of implementation. Time spent
surprise: I spent less time thinking of implementation. catching bugs, easy implementation
surprise: I spent less time thinking of implementation. Predefined test templates allow you to write test cases in no time if they are known.
surprise: I spent less time thinking of implementation. The design decisions seemed to almost "fall out" of the tests.
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).
surprise: I spent less time thinking of implementation. Thinking about the test first made the code easier to implement.
surprise: I spent less time thinking of implementation. easier than expected to come up with tests.
surprise: I spent less time thinking of implementation. Given a well defined series of tests, implementation seemed lighter as a task.
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
surprise: I spent less time thinking of implementation. Having tests gives you more confidence in making changes.
surprise: I spent less time thinking of implementation. The interface and implementation seemed to emerge somewhat naturally from the requirements.
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!
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.
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.
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.
surprise: I spent less time thinking of implementation. no fear! gives a relaxed systematic approach
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.
surprise: I spent less time thinking of implementation. Starting not focusing on the implementation of the system but the core interaction of the system
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.
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.
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!
surprise: I spent less time thinking of implementation. Incremental building of code
surprise: I spent less time thinking of implementation. More easy to write functions code
surprise: I spent less time thinking of implementation. less time thinking about the implementation
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
surprise: I spent less time thinking of implementation. I was surprised at how it took some of the load off of thinking about implementation and placed emphasis on the design should behave and function.
surprise: I spent less time thinking of implementation. The overall feel is slowed down and more very small steps than I am used to but this seems appropriate when testing on the smallest level.
surprise: I spent less time thinking of implementation. It is fast an easy
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.
surprise: impl-less I spent a lot less time thinking about implementation.
surprise: Improvement This course will help developers avoid bugs.
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
surprise: incremental more and more completely considered
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)
surprise: incremental Small incremental steps actually lead to final solution.
surprise: Inefficient That you write implemention code at times that isn't the true implemention.
surprise: insight It provides a good insight into the process of coding
surprise: integrated Thought it was write test then write code, much more integrated
surprise: integrity write a code that shall work for ALL cases with intended behavior.
surprise: interesting interesting
surprise: iterative That decent, working code can be made iteratively, even though we started with horribly hacky code.
surprise: ItsNeverTooLateToLrn This is a very useful tool for development. I should have known much earlier :)
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.
surprise: lies easier than you think to have bad code pass
surprise: Light? Getting up and running doesn't seem to require much in terms of "infrastructure" to support the framework.
surprise: like it I like it more than I thought I would
surprise: long-process how long it takes to do TDD
surprise: LowThreshold How easy it was to get started.
surprise: LowThreshold How easy it was to get started.
surprise: managed testcase Get systematically managed testcase
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.
surprise: many test case success many test cases more as I expect.
surprise: meaningful It really makes the codes meaningful.
surprise: microsteps Writing only as much code as is actually required to pass the tests.
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.
surprise: mistakes That I write the code as well as the tests.
surprise: nice It's pretty straight forward.
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.
surprise: no surprises There is no suprise really. Its known but the value is realised when everbody practises it diligently.
surprise: none none
surprise: None No real surprises yet.
surprise: None None but I've been doing TDD for 10 years now.
surprise: None. You modified your test as long as you are developing the code, you procrastinate a lot more than I expected
surprise: None. Easy to get started.. (?)
surprise: None. Small dynamic development steps, allows for simplistic thought on design
surprise: None. I am surprised that aside from learning the new tools the TTD implementation is straightforward.
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.
surprise: None. code will be fully tested
surprise: None. I was surprised by how quick the implementation of the functions be tested was progressing
surprise: None. It seems to be a very thorough way of making your code robust
surprise: None. The concept is ease but thinking of implementation take more.
surprise: None. simpler approach
surprise: None. simpler approach
surprise: None. still in surprise
surprise: None. No surprises here!
surprise: None. Nothing
surprise: None. test surprise
surprise: None. There is a test framework. I don't always use a test framework but often end up building one for that code.
surprise: None. surprised how much more time I spent writing tests vs writing code. Much more time in the tests.
surprise: None. I haven't done c for quite a long time.
surprise: None. It's kind of fun after you get in the groove.
surprise: None. TDD is nothing new to me.
surprise: None. let tests fail first
surprise: None. Surprising is the concequence with which the method is done by you.
surprise: None. Now we are only taking about unit tests. What about integration tests of our modules?
surprise: None. I like the quality
surprise: None. Bugs are found fast.
surprise: None. Certain success with dummy code
surprise: None. Certain success with dummy code
surprise: None. hard coding at first, then change it when the test fails
surprise: None. How much fun it is!
surprise: None. interesting interactive approach both code testing and through online learning experience
surprise: None. At first my mind will lead me to start writing complete structure/ functions instead of following test. Even the test is there.
surprise: None. i am suprised that how will it be time saving ?
surprise: None. I make quite a bit of mistakes :)
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.
surprise: None. Making the function fail first
surprise: None. The immense DOPAMINE RUSH from refactoring code.
surprise: None. we spent an hour writing a buffer and didn't get to writing the actual buffer object
surprise: None. It's very effective from the beginning.
surprise: None. It's very effective from the beginning.
surprise: None. It's very effective from the beginning.
surprise: None. It's very effective from the beginning.
surprise: not at all I already use it.
surprise: Not yet surprised I am not easily surprised :)
surprise: nothing Nothing.
surprise: nothing not sure
surprise: nothing I've been doing this for personal side projects, so not a surprise.
surprise: Nothing Nothing
surprise: Nothing No surprise
surprise: Nothing. No surpises yet
surprise: Nothing. Nothing really as such. Somewhat familiar with the concept.
surprise: Nothing. There is no surprise, is what I expect.
surprise: Nothing. I have not read or heard about TDD before so I didn't really have any expectations
surprise: Nothing. Nothing since I already practice is.
surprise: Nothing. I was slightly familiar with TDD, so not completely surprised (yet) ;)
surprise: Nothing. None
surprise: Nothing. -NA-
surprise: Nothing. No surprises.
surprise: Nothing. No surprises.
surprise: Nothing. I am already familiar with the theory, so nothing surprising for me.
surprise: Nothing. Nothing surprised me
surprise: Nothing. works as expected
surprise: Nothing. N/A...
surprise: Nothing. I've done simular trainnings in the past :D
surprise: Nothing. No surprises
surprise: Nothing. It created some good coding concepts for engineers to have good coding behaviors.
surprise: Nothing. Nothing
surprise: Nothing. Nothing
surprise: Nothing. Nothing yet.
surprise: Nothing. Nothing yet.
surprise: Nothing. TDD should reduce amount of surprises.
surprise: Nothing. Nothing.
surprise: Nothing. Nothing surprised me as I have done this type of coding at Pivotal.
surprise: Nothing. I had TDD explained to me once by a senior developer. Similar to the process explained here
surprise: Nothing. No surprises no far. I don't know if I'm doing TDD right.
surprise: Nothing. I think many programmers may be doing tdd but do not realize.
surprise: Nothing. so far no surprises
surprise: Nothing. jhghjhgkjhgh
surprise: Nothing. nothing
surprise: Nothing. Really!
surprise: Nothing. Its about what I expected.
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 :)
surprise: Nothing. I follow normally TDD in my job. Sometimes logic used in first development needs complete change after TDD.
surprise: Nothing. It is as expected.
surprise: Nothing. Nothing
surprise: Nothing. Nothing
surprise: Nothing. it might reduce the cost of fixing the bugs
surprise: Nothing. Can't be surprised, very new to this type of flow
surprise: Nothing. It's about what I expected.
surprise: Nothing. So far nothing, but I have used it before
surprise: Nothing. Nothing so far :)
surprise: Nothing. Nothing
surprise: Nothing. None so far.
surprise: Nothing. I've been exposed to TDD before, so no real surprises
surprise: Nothing. No big surprises at this point
surprise: Nothing. No surprises so far.
surprise: Nothing. I've done TDD for a while, so this was not a surprise.
surprise: Nothing. Not much really
surprise: Nothing. No surprises
surprise: Nothing. nothing so far
surprise: Nothing. There is no surprise for me.
surprise: Nothing. ı surprised about how much friendly is james :) Salute that man!
surprise: Nothing. Business as usual.
surprise: only what's needed Only focusing "on the next thing" ... only adding test functionality up to what you need now/next
surprise: oops How you can defer design and implementation.
surprise: Other. 3. How confused you can get :)
surprise: Other. I'm surprised that there are still other ways to do development.
surprise: Other. It takes my brain a lot of time to think in this new way. Still skipping ahead too quickly
surprise: Other. It is easy to understad, but I need to see that it really improves how I actually code (zero bugs).
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 )
surprise: Other. Ability to find memory leaks
surprise: Other. How it helps to keep structured.
surprise: Other. Hard to keep train of thought. When switching between writing implementation and tests.
surprise: Other. learning a different methodology
surprise: Other. Finding earlier tests that started to fail after refactor. Neat!
surprise: Other. The iterative nature and co-writing tests along with the code functionality.
surprise: Other. The want to write multiple tests before I write any code.
surprise: Other. TDD gives me feedback right away when i make mistakes.
surprise: Other. that all the edge cases seem to tidy up quite quickly
surprise: Other. I am intrigued at the implementation process the follows TDD
surprise: Other. Gathertown is a neat platform
surprise: Other. Gathertown is a neat platform
surprise: Other. When I would break an early simple test with a small change
surprise: Other. Allows for closer inspection of the foundational elements of the code. Things that may get rushed through because it is "basic".
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.
surprise: Other. I made to many errors
surprise: Other. It takes even more time than I expected. So many intermediate steps have to be removed afterwards.
surprise: Other. too early to form an opinion
surprise: Other. I like testing now. I feel better as an engineer.
surprise: Other. I ended up implementing things differently than I had prior to Module 1. While both implementations are identical from the outside, I think the TDD code is cleaner and simpler due to the approach used
surprise: Other. I was a bit surprised by the runtime constructor being the first thing on the page in an embedded C class
surprise: Other. no surprise yet
surprise: Other. is becomes like another code review - when it is hard to test then the code is weak.
surprise: Other. is becomes like another code review - when it is hard to test then the code is weak.
surprise: Other. Big amount of test cases.
surprise: Other. ccpuTest pointing out memory leaks
surprise: Other. How it is possible to be driven by testing. Targeting testing will lead you to the final solution, without realizing it.
surprise: Other. How much I was taking for granted with my existing approach to implementation
surprise: Other. Having to think about memory issues :)
surprise: Other. Surprised that I can still remember some C syntax.
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.
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.
surprise: Other. The first time I encountered TDD, the fact that not being able to compile was considered failing tests.
surprise: Other. How fast I can go because of my confidence.
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.
surprise: Other. I am suprised how easy it is to implement more than its actually needed
surprise: Other. The tests catch memory leaks. (ie more thorough than what I was expecting)
surprise: Other. Like the integration of other analysis (mem-check).
surprise: Other. Testing before writing code
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.
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
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
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
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
surprise: Other. The immense DOPAMINE RUSH from refactoring code.
surprise: Other. How the tests shaped the design of my code and kept it simple.
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.
surprise: Other. Dynamic memory error messages were clear and useful. Constructor one was not.
surprise: Other. It helps you manage expectations of what a piece of code should be doing.
surprise: Other. I was surprised to realize the usefulness of how a thorough test suite can provide a good means of regression testing.
surprise: Other. The TDD strategy makes the .h, .c and TEST.cpp very clean and organised. It improves readability.
surprise: parallel That the test cases are designed in parallel with developing code.
surprise: passing Just focusing on passing the test and not implementing the complete solution
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
surprise: prevent prevent exception situation.
surprise: priority That I am worried about testing first and then development.
surprise: procrastination Procrastinating to break down the problem.
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)
surprise: productivity I'd be surprised to see productivity with that big overhead of testing up front
surprise: Progress You see the progress. If you feel like "have I thought about xyz?" you write the xyz test.
surprise: Quick feedback A very quick feedback as to what you're doing wrong.
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.
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
surprise: reduce debug time Increase development time at first but reduce the debugging time later
surprise: regression How quickly the unit tests provided a simple regression test suite.
surprise: regressions structural changes may cause some detective work to get underway, clearly tracking back regressions takes practice.
surprise: RegressionTest Regression Test automatically.
surprise: requirements That it was possible to get functioning code without a full understanding all the requirements at the start
surprise: requirements No mention of requirements or how they feed into tests.
surprise: Reversed Writing code to fit test rather than the other way around.
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
surprise: Safety nets TDD makes me stick to green when i make mistake.
surprise: safety-first That I ever dared to touch legacy code or develop new code without the safety net of continuous and automatic verification.
surprise: satisfying The small victories of passing one test at a time were satisfying.
surprise: short With how little implementation you can get away. And, how clean this implementation is.
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.
surprise: simple Simple concept
surprise: simple Test code is very simple
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.
surprise: simplicity How simple TDD can make programming.
surprise: simplicity How simple TDD can make programming.
surprise: Simplicity The simplicity of some of the tests
surprise: simplicity the simplicity so far
surprise: simplicity Its simple to write tests
surprise: SLOW I felt that the steps/increments were a bit small.
surprise: small steps how incremental the procedure can be
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).
surprise: small steps About making changes in quite as small pieces.
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.
surprise: Speed The speed with which I could write test cases and functionality simultaneously. I expected it to be more time intensive.
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.
surprise: speed It was faster than I thought.
surprise: speed How rapid it can be to iteratively add functionality.
surprise: straightforward It is far more straightforward than first thought.
surprise: Strong Very easy, simple for understand
surprise: Surprise Its not as easy to write code under the TDD paradigm than I thought it would be.
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.
surprise: systematic solution There is a systematic way to avoid creating bugs while writing codes.
surprise: TDD is different than I thought. How big a mindset change TDD requires
surprise: TDD is different than I thought. It changes and challenges the brain routing for coding. I realized during the exercises that it was difficult to keep my brain to do things in a structured way, one step a time. This is good.
surprise: TDD is different than I thought. That you write things you know is going to fail.
surprise: TDD is different than I thought. felt relaxed while coding
surprise: TDD is different than I thought. surprise test
surprise: TDD is different than I thought. That it is truly test driven development - tests drive the development like cart driving the horse.
surprise: TDD is different than I thought. That it is truly test driven development - tests drive the development like cart driving the horse.
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.
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.
surprise: TDD is different than I thought. The name. I think it's wrong. This isn't testing.
surprise: TDD is different than I thought. it is fun :)
surprise: TDD is different than I thought. It is more of a practice/mindset than a methodology
surprise: TDD is different than I thought. The change in mindset that is required.
surprise: TDD is different than I thought. I was surprised by how iterative it was.
surprise: TDD is different than I thought. not what I expected
surprise: TDD is different than I thought. not what I expected
surprise: TDD is different than I thought. Its effectiveness .. Like never look back for that particular usecase again once passed
surprise: TDD is different than I thought. -Felt exciting to write a failed test, and then fix it.
surprise: TDD is different than I thought. I was surprised that it forced me to remove/eliminate irrelevant code.
surprise: TDD is different than I thought. Surprised by how tedious it is.
surprise: TDD is different than I thought. How much it made me think about how to write "good" code as I go. Usually have waited until the very end to write tests and it turns into a dumpster fire.
surprise: TDD is different than I thought. How much C code I don't remember. Also, once I caught one, the approach made more sense to me, and looks like a valuable coding method.
surprise: TDD is different than I thought. I was expecting tests to happen at a larger scale. Interesting how even small programs could have hundreds of tests.
surprise: TDD is different than I thought. How much C code I don't remember. Also, once I caught one, the approach made more sense to me, and looks like a valuable coding method.
surprise: TDD is different than I thought. I was expecting tests to happen at a larger scale. Interesting how even small programs could have hundreds of tests.
surprise: TDD is different than I thought. I was expecting tests to happen at a larger scale. Interesting how even small programs could have hundreds of tests.
surprise: TDD is different than I thought. That the tests are written before writing the code.
surprise: TDD is different than I thought. I was not expecting that I would be taught to write code just to pass a test, but that code is not the code that will then be in the last version of the code and shipped out.
surprise: TDD is different than I thought. Encourages procrastination
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.
surprise: TDD is different than I thought. test surprise
surprise: TDD is different than I thought. It looks simple, but actually reliable when it comes to testing code.
surprise: TDD is different than I thought. It will take some time to think about the test case. And test code steps by steps.
surprise: TDD is different than I thought. The concept is ease but thinking of implementation take more time.
surprise: TDD is different than I thought. Different thought. I never consider the test case before I really program the production code.
surprise: TDD is different than I thought. It was a interactive session, I forgot some corner cases.
surprise: TDD is different than I thought. TDD is different than I thought
surprise: TDD is different than I thought. Thinking of new testcases came sooner when doing ding along side coding.
surprise: TDD is different than I thought. still in surprises
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.
surprise: TDD is different than I thought. quick feedback
surprise: TDD is different than I thought. I thought it was "write all tests first, then implement" but it's at the same time.
surprise: TDD is different than I thought. It is a satisfying process.
surprise: TDD is different than I thought. It's definitely a new way of thinking for me, but it works and is a workaround for the confirmation bias problem we face when writing tests after implementation
surprise: TDD is different than I thought. It's different than what was my initial impression.
surprise: TDD is different than I thought. I had misunderstood what "write minimum code" meant in the TDD context. But it all works out in the end :)
surprise: TDD is different than I thought. I had misunderstood what "write minimum code" meant in the TDD context. But it all works out in the end :)
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.
surprise: TDD is different than I thought. You start first writing the test before you start with the solution
surprise: TDD is different than I thought. The step-by-step approach is different than the "usual" tests that I write.
surprise: TDD is different than I thought. That I remember pointers.
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!
surprise: TDD is different than I thought. it is quick to add test, run and get feedback
surprise: TDD is different than I thought. concern 1024
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
surprise: TDD is different than I thought. Different way to look at the problem.
surprise: TDD is different than I thought. That the steps would be that SMALL
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.
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.
surprise: TDD is different than I thought. I didn't know such a pre-canned test environment existed.
surprise: TDD is different than I thought. To test one feature implementation, it could need multiple TDD test cases to cover this single feature.
surprise: TDD is different than I thought. Writing Test code before doing the "right" stuff!
surprise: TDD is different than I thought. Up to now "strange" procedure.
surprise: TDD is different than I thought. One surprising aspect is how different it feels to implement TDD versus learning about it.
surprise: TDD is different than I thought. I needs some rethinking, but if you are willing to change its an instant improvement.
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
surprise: TDD is different than I thought. It doesn't seem as boring as I expected it to be at first.
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 (:
surprise: TDD is different than I thought. This platform is pretty much interactive to work collaboratively.
surprise: TDD is different than I thought. How "noobish" and out of depth i feel ( might be a good sign )
surprise: TDD is different than I thought. I thought I knew more-or-less what TDD is, but I knew nothing :D
surprise: TDD solves corners It is surprisingly good tool to verify the corner cases in very user friendly framework.
surprise: TDD was easier than I thought. How easy it is to start writing and running test from the begging
surprise: TDD was easier than I thought. Make tests fail on purpose first
surprise: TDD was easier than I thought. TDD is easier to start with than the complexities I earlier thought of
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.
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.
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.
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.
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.
surprise: TDD was easier than I thought. It surprised me how it was easier to structure the problem.
surprise: TDD was easier than I thought. Once you start to write code to pass tests, the process becomes easier.
surprise: TDD was easier than I thought. I was surprised at how easy it was to continue with the testing once you got started. I was expecting each step to take roughly the same amount of time but they got progressively easier.
surprise: TDD was easier than I thought. It was relatively easy to create test cases alongside the production code.
surprise: TDD was easier than I thought. Went in with no clue about TDD, but starting to see a pattern of create test, define function, write function, test, rinse, repeat.
surprise: TDD was easier than I thought. It wasn't that bad.
surprise: TDD was easier than I thought. TDD was easier and helps to develop quality software.
surprise: TDD was easier than I thought. It's pretty easy and fun :)
surprise: TDD was easier than I thought. different mindset with legacy programmer.
surprise: TDD was easier than I thought. Even a simple test cases can capture critical bugs
surprise: TDD was easier than I thought. It is easy that I though and I can add more features easily.
surprise: TDD was easier than I thought. That writing tests to check behavior is not the standard to begin with (I don't understand how one could claim their code works without testing the behavior)
surprise: TDD was easier than I thought. It was relatively easy.
surprise: TDD was easier than I thought. How easy and simple it is.
surprise: TDD was easier than I thought. Interface was different. Very simple to navigate
surprise: TDD was easier than I thought. It is easy if the tests are already laid out
surprise: TDD was easier than I thought. It was not to hard to implement the practice.
surprise: TDD was easier than I thought. At how simple it is. Your approach matters and will confuse you at the same time.
surprise: TDD was easier than I thought. How easy it is to follow the ethos/paradigm. When you are someone who has never followed this approach it's not a big change to how you would normally work (short learning curve so far)
surprise: TDD was easier than I thought. I didn't have to throw away much "fake" code
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.
surprise: TDD was easier than I thought. It's a lightweight / simple process
surprise: TDD was easier than I thought. it improves the efficiency of the code developed
surprise: TDD was easier than I thought. Nice development environment
surprise: TDD was easier than I thought. that is more easy to do than expected (once the tool setup is done)
surprise: TDD was easier than I thought. Small incremental steps are good.
surprise: TDD was easier than I thought. There is not much to it, is like eating an elephant "one spoon at the time."
surprise: TDD was easier than I thought. In many ways, its simple.
surprise: TDD was easier than I thought. Its simple!
surprise: TDD was easier than I thought. Not sure whether we write too many tests or too little?
surprise: TDD was easier than I thought. Easy to work with
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!)
surprise: TDD was easier than I thought. It's straight forward and simple.
surprise: TDD was easier than I thought. How easy it was.
surprise: TDD was easier than I thought. Degree of feedback from the tool, and it was easier to use than expected.
surprise: TDD was easier than I thought. How easy it is
surprise: TDD was easier than I thought. Less complex, than I thought.
surprise: TDD was easier than I thought. Catching problems earlier and realizing how often as developers we get ahead of ourselves.
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.
surprise: TDD was easier than I thought. How easy it feels after learning curve/
surprise: TDD was easier than I thought. - Seems easier to get the hang of/integrate into my workflow than I originally though
surprise: TDD was easier than I thought. It's super easy to implement.
surprise: TDD was easier than I thought. How much easier it makes it to break down a problem.
surprise: TDD was easier than I thought. -------
surprise: TDD was easier than I thought. Felt easier than expected, but we were guided. Might be different from a blank slate.
surprise: tdd_cycle How quickly it was to adjust to the TDD cycle.
surprise: test before code Think about test before coding
surprise: test coverage I felt it is not easy to make test design for good test coverage
surprise: test reliant The tests can be written incorrectly to pass code that does not work.
surprise: Test Tool Didnt expect some nice feedback that CPPUTEST gave me when tests failed.
surprise: That it works! - constructing source code has always failed
surprise: That it works! Easy framework, keep production code simple
surprise: That it works! If test plan is covering all requirements, we end up developing everything that is needed.
surprise: That it works! It is really finding the bugs early
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.
surprise: That it works! the compiler displaying total tests run in the output result
surprise: That it works! Its ability to catch errors with each line of code I write.
surprise: That it works! it is light-weighted and easy to perform
surprise: That it works! None
surprise: That it works! None
surprise: That it works! It works well in this module 1
surprise: That it works! It was easier than I thought
surprise: That it works! TDD looks at all the boundary conditions and fully tests them!
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.
surprise: That it works! How much i'd enjoy it
surprise: That it works! It's easy to start with
surprise: That it works! helps in in maintaining a continuous focus on software quality
surprise: That it works! in every step it is clear what is working and you can exactly prove it
surprise: That it works! It works! mistakes are easy to identify in time
surprise: That it works! I think TDD is helpful to avoid bigger/critical bugs later in the development stage or after release.
surprise: That it works! It surprised me how effective and well it worked.
surprise: That it works! It surprised me how effective and well it worked.
surprise: That it works! It works
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.
surprise: That it works! The number of bugs that were detected by tests.
surprise: That it works! That the test was written for us to complete the exercise.
surprise: That it works! the advantages for demonstrate to the customer, low level requirements through unit tests.
surprise: That it works! Hard to set up good coverage but in the end, the tested code works
surprise: That it works! how easy is make mistakes.
surprise: That it works! It's very satisfying to see the code do what you've "predicted" it will do
surprise: The small steps! Got quite far before actually allocating the buffer
surprise: The small steps! Implement step by step. Easier to process.
surprise: The small steps! Amount of fake implementations when getting tests to pass
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
surprise: The small steps! Incremental coding, writing the tests first and make them fail before coding
surprise: The small steps! Both implementation and validation in one.
surprise: The small steps! A different approach/view to deal with new modules programming
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.
surprise: The small steps! The structure of it can assure you that you didn't leave any code without testing.
surprise: The small steps! The micro steps of it
surprise: The small steps! Doing the TDD should be made in small steps.
surprise: The small steps! Why didn't I learn about this at University?
surprise: The small steps! The small steps
surprise: The small steps! -There can be a lot of debugging for writing tests. -It helps you to focus on more specific tasks.
surprise: The small steps! The flow of using it can be smooth and efficient.
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.
surprise: The small steps! At way the design is slowly taking shape, driven by the tests.
surprise: The small steps! It was much easier to start tackling the problem slowly with TDD than going all in coding.
surprise: The small steps! It was nice to write code incrementally
surprise: The small steps! It is refreshing way to see in incremental steps with tests tied with them
surprise: The small steps! Going in, I had a simplistic view of TDD: Write tests first, then implementation. The short feedback cycle is interesting.
surprise: The small steps! small steps: first make compiler fail, make linker fail, let test fail, make test succeed.
surprise: The small steps! Granular Iterative Approach
surprise: The small steps! I was surprised at how little code was needed to pass each test.
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.
surprise: The small steps! Its a different way to test/write code, which once a person fully understands, could greatly benefit an organization.
surprise: The small steps! when i heard about TDD i didn't think it could fir so well in an agile organization of software development. it seems to me the direct translation of agile principles into tests development
surprise: The small steps! It tests and develops at the same time.
surprise: The small steps! Initial steps are tiny but the more tests we have the more time it requires to fix non-passing tests
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
surprise: The small steps! If you are in an environment enabled for TDD, it is really simple to begin using TDD
surprise: The small steps! It started to make some sense and use of the test.
surprise: The small steps! how many steps it took
surprise: The small steps! I have to rewire my brain to think in smaller steps
surprise: The small steps! Steps are so small they don't feel productive, or leading in weird directions.
surprise: The small steps! I was surprised, and liked, the impact of including code coverage in the test results ("You've coded ahead of your test")
surprise: The small steps! Plenty of smaller test for your functionality.
surprise: The small steps! UtestMacros.h -- Keeping the tests simple to testing one feature at a time. I put several tests together in module 0. But when I think about it, it's a better checklist to have simple tests.
surprise: The small steps! This forces you to change one thing at a time and test it. I never noticed before, but when I change "one thing" I actually changed a dozen little things...
surprise: The small steps! It is hard not to think about the next couple of steps when implementing something
surprise: The small steps! It surprised me how little I had to think ahead to reach a solution. I often have a hard time breaking complex software tasks down into manageable pieces.
surprise: The small steps! How small some of the steps are
surprise: The small steps! surprised as it is hard to think about the tests for the simple code
surprise: The small steps! The small steps and iterative development
surprise: The small steps! How simple it is to write a test
surprise: The small steps! How simple it is to write a test
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
surprise: The small steps! Usually write probably entire class at least as a blueprint and test. Where it is likely to ignore/miss code testing at this granularity
surprise: The small steps! How doing the least work possible to a pass a test makes the most sense.
surprise: The small steps! The code for the first few tests are sparse
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.
surprise: The small steps! Small steps!
surprise: The small steps! Little tiny steps, and writing code that ignores what I want the function to do
surprise: The small steps! Teeny tiny iteration
surprise: The small steps! We learn a lot!
surprise: The small steps! Some of the things I do it in my day-to-day job
surprise: The small steps! UI is awesome. It surprised me.
surprise: The small steps! Small steps in code writing makes easy to find the bugs at early stage.
surprise: The small steps! there are so many small test cases which we generally skip during our testing
surprise: The small steps! Small & simple steps
surprise: The small steps! Small & simple steps
surprise: The small steps! Small & simple steps
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.
surprise: The small steps! TDD keeps you focused while designing without overthinking your approach.
surprise: The small steps! The granularity was very surprising. I would have though of it in bigger chunks of work on each side (test <-> code) in each step.
surprise: The small steps! Such small steps/iterations
surprise: The small steps! It doesn't seem so scary to write all the unit tests when you separate everything into small steps before the actual implementation.
surprise: The small steps! its easier to have first simple implementation and building on that, helps structuring the thoughts but maybe taking more time.
surprise: The small steps! its easier to have first simple implementation and building on that, helps structuring the thoughts but maybe taking more time.
surprise: The small steps! I'm surprised I have not been using this all along
surprise: The small steps! It is hard to do SMALL changes.
surprise: The small steps! Using just the small steps to get the buffer working by just using test cases.
surprise: The small steps! train me how to *hack* the code as going into the exercise.
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.
surprise: The small steps! Harder to stop myself from fully implementing functions than I expected.
surprise: The small steps! Increments are maybe smaller than expected.
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.
surprise: The small steps! I was surprised by how small of steps TDD uses. Typically I implement a function at a time as my smallest step, but with TDD, I wasn't even implementing an entire function at a time.
surprise: The small steps! How much of a simple guideline it creates for defining behavior and creating a process to develop the behavior.
surprise: The small steps! The very small increments in the process of TDD
surprise: The small steps! I like doing things in small steps.
surprise: The small steps! Writing tests knowing that it will fail
surprise: The small steps! How it starts with the simplest of tests and then starts getting built up.
surprise: The small steps! The small steps it takes to build something big, and how easy it is to manage.
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?
surprise: The small steps! Taking very small steps at each compile was surprising but effective.
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
surprise: The small steps! Just how small units of functionality can be
surprise: The small steps! Just how small units of functionality can be
surprise: The small steps! Tendency to stick to what you are used to. Hard hard time convincing my partner and myself to go step at a time.
surprise: The small steps! Tendency to stick to what you are used to. Hard hard time convincing my partner and myself to go step at a time.
surprise: The small steps! That the incremental steps can be extremely small, even for obvious concepts.
surprise: The small steps! How small a code change is needed
surprise: The small steps! I did not realise how small the iterations were
surprise: The small steps! You can produce a lot of positive test results without having any functionality. return 42
surprise: The small steps! I was surprised that concerns can be separated much more easily.
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.
surprise: The small steps! The steps are so small... it takes some extra thinking I'm not really used to :)
surprise: The small steps! The really small steps... functions are doing nothing at the beginning.
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.
surprise: The small steps! small steps, but it seems to work
surprise: The small steps! How hard it can be to only take such small steps.
surprise: The small steps! It is difficult to not write directly a full implementation.
surprise: The small steps! That you don't do any implementation before the tests.
surprise: The small steps! - The Tooling - The simplicity of the individual tests
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
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.
surprise: The small steps! Tests can be very simple and don't have to test complicated operations.
surprise: The small steps! I really like to way to code evolve in small steps. It was also easier than I expected, plus very rewarding at the end.
surprise: The small steps! How hard it is to only do baby steps. How far you get with fakes.
surprise: The small steps! small steps make quality code.
surprise: The small steps! The amount of things tested in each test was smaller than anticipated
surprise: The small steps! I was surprised at the speed of iteration cycles.
surprise: The small steps! Test conacept should be clear already before, is this every time the case ?
surprise: The small steps! I actually like the splitting. I helps to improve coverage and structure. But needs development time ...
surprise: The small steps! only think to the next step 'Live today' ;)
surprise: The small steps! Certain success with dummy code
surprise: The small steps! Very small work steps.
surprise: The small steps! each small steps make sure the existing code works.
surprise: The small steps! Code changes are very small
surprise: The small steps! It is fun
surprise: The small steps! I'm surprised how production code grow up. (but I also see situations where, using TDD, it does not happens)
surprise: The small steps! That even with TDD, your website crashes!
surprise: The small steps! the small steps -- too small ? it's disorienting.
surprise: The small steps! alot smaller steps taken to be diligent about writing code
surprise: The small steps! As a generic method it surely has a large spectrum of applications
surprise: The small steps! How hard it is to "compile" (test) the code so often.
surprise: The small steps! Testing each incremental change
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.
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.
surprise: The small steps! How one can tease out functionality to get to really fine granularity on logic
surprise: The small steps! How small steps should actually be
surprise: The small steps! the fast feedback loop helps keep pace and momentum moving forward.
surprise: The small steps! I found it easier to construct a complex test by adding 1 test at a time and checking it.
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
surprise: The small steps! Writing test cases instead of design is still very counterintuitive.
surprise: The small steps! It is great way to focus the mind on small and incremental details in a design.
surprise: The small steps! Code is written in very small steps makeing it easier to impliment.
surprise: The small steps! You can face a problem with small steps.
surprise: The small steps! How confident I am in my code after passing the tests.
surprise: The small steps! Literally the tiny steps of doing the development.
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).
surprise: The small steps! Now I have to think of taking small steps for my coding approach. I have to learn this from scratch.
surprise: The small steps! TDD is an overall weird experience. fun, but weird as you have said before the exercise.
surprise: The small steps! The fact that I'm forced to progress sequentially and not able to just implement the functionality from scratch.
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.
surprise: The small steps! "Do the simplest thing that could possibly work"
surprise: The small steps! How many times I write extra implementation that's untested.
surprise: The small steps! Some assumptions even for simplest tasks can get you.
surprise: The small steps! The small size and frequency of the test/code cycles.
surprise: The small steps! I appreciate the smaller steps during the development.
surprise: The small steps! Incremental testing and implementation.
surprise: The small steps! The granularity of the steps.
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.
surprise: The small steps! Getting the application ready step by step is really nice. The "basics first" apporach is nice.
surprise: The small steps! It was surprising that most of the tests just involved returns
surprise: The small steps! It is slightly more frustrating and more enjoyable at the same time to go in small steps.
surprise: The small steps! How small the development steps that you take can be. I was expecting bigger, more comprehensive iterations.
surprise: The small steps! Take baby steps. Make it simpler first, test it, and then gradually increase complexity.
surprise: The small steps! The method can be applied to different programming languages, probably.
surprise: The small steps! small steps
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.
surprise: The small steps! initial goal gets split into (very) small pieces, with each beeing easy to test
surprise: The small steps! How small the steps are.
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.
surprise: The small steps! I did not thing the steps would be so small. I think this makes it appear slow.
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.
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.
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
surprise: The small steps! Almost each step needs to be tested.. It is easy to forget that often..
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.
surprise: The small steps! Usually I want to jump into developing whole solution - TDD makes you think about solution more before writing everything.
surprise: The small steps! I liked the small cycles.
surprise: The small steps! How small the steps can be.
surprise: The small steps! How difficult it was to come up with minimal solutions to minimal tests
surprise: The small steps! Surprised at how small of a change we should make to our code in order to pass a test.
surprise: The small steps! Surprised at how small of a change we should make to our code in order to pass a test.
surprise: The small steps! It has always surprised me how short steps empowers us
surprise: The small steps! Every step is very small
surprise: The small steps! development increment process
surprise: The small steps! I enjoyed how incremental it felt and how it broke down everything into smaller steps.
surprise: The small steps! It is testing basic steps that you never thought of testing.
surprise: The small steps! At any given point, for the functionality implemented, it is guaranteed that it is completely tested
surprise: The small steps! Easy to work with small steps.
surprise: The small steps! You can get positive feedback on your implementation quickly and traceably.
surprise: The small steps! Applying TDD shows that every piece of code you write contains so many choices and consequences
surprise: The small steps! Approaching each test with minimal effort reduces complexity in development and lowers the risk of creating bugs.
surprise: The small steps! I previously had the mistaking impression that TDD was write tests beforehand and then move on to implementation.
surprise: The small steps! Nothing surprising so far.
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.
surprise: The small steps! small steps -> fast fixes
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.
surprise: time The development speed was a bit slower, but more evenly paced with less staring - overall a win time wise.
surprise: time more time consuming than expected
surprise: time saver How easy it is to catch what could otherwise be hard issues to solve
surprise: totally new First time I know TDD
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.
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
surprise: useful You can always find meaningful test cases even if the problem seems trivial
surprise: usefully Yeah! It's so usefully to test and check the code. It's very usefully to save the time for fixing bugs.
surprise: web ui very easily run in the web ui
surprise: Wild Explicitly de-emphasizing requirements on initial iteration cycles.
surprise: wondering The lack of forward thinking in writing code that will knowingly fail tests later.
surprise: workflow. Such a different workflow.
surprise: works it works!!
surprise: Zero Nothing. I have been exposed to TDD before.