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