What concerned 1370 people about their first TDD experience

Course code Kind In a Word Impressions
A**-1 concern Does not fit how I code. Need the idea to be clear in advance
A**-1 concern Hard to think of the tests too extra work
A**-1 concern Hard to think of the tests I wonder how easy will it be to implement it with more complex code, not so easy to test
A**-1 concern Hard to think of the tests Not designing well the test or taking the wrong approach
A**-1 concern Hard to think of the tests Hard to cover all aspects and not miss any feature to test. If you feel too confident after testing it could fail anyway.
A**-1 concern Other. I could miss some functions with hardcoded return values or some cases without being properly tested.
A**-1 concern Other. Complex modules are difficult to test, sometimes modules are not so easy to test (most of times because the design is wrong). The test framwork probably wont' compile on my embedded systems.
A**-1 concern Other. You might forget of some harcoded value that you wrote just to make a test pass that interfiers know with another test
A**-1 concern There is no design. Think before coding
A**-1 concern There is no design. It feels like you are going to forget to modified the initial simple tests as you modified them on demand.
A**-1 concern Too much test code. For simple problems it requires more time to think and write the tests, than to write the solution.
A**-1 concern Too much test code. The concept of more test code than production code, implies more code to maintain
A**-1 concern Too much time. It is taking much time to get a circular buffer to work properly. Maybe this implementation can be more safe but I am not really sure
A**-1 concern Too much time. Waste of code
A**-1 concern Too much time. The structured approach can take some time for basic tests.
A**-1 concern Where are the requirements? I think is important to know the requirements before start with the deployment
A******-2 concern Very myopic focus made it hard to work on the problem holistically. I feel like I wouldn't have had to refactor my implementation as many times if I were working in a test-concurrent fashion.
A******-2 concern It seems very time consuming at first. Might take a while to get comfortable with.
A******-2 concern There are some small, tedious steps that I forget fairly often.
A******-2 concern It feels a little unnatural. It can be hard to mentally buy in to the idea of testing something that doesn't event exist yet (at least in the very beginning).
A******-2 concern It might take a considerable amount of practice to utilize it properly.
A******-2 concern You might get stuck in the trap of coding first without a good design in mind and end up down the wrong path.
A******-2 concern My concerns are how do you start this with no class definition and instead at the user story level. What should be the process from getting a user story to a class api.
A******-2 concern I am not sold on writing a failing test to begin with, that won't compile. I prefer to have a design, start implementing small portions of a class, then writing some tests to exercise the new code. We'll probably get to this, but the test code can get to be sprawling in larger projects with multiple contributors if left unchecked. This leads to a lot of technical debt over time. However, there are ways around it with test fixtures as one example.
A*-1 concern All the above. Slow - continuous change of focus could take you out of the zone Fake it till you make it - fake stuff getting stuck in the code Fragile test problem - hard to refactor bad interface decisions
A*-1 concern Does not fit how I code. It's very different from how I usually work, and I need think in a different way. At the moment I can solve problems faster with my usual method (might get better after getting used to the method)
A*-1 concern Does not fit how I code. It felt artificial to only create minimal implementations that you knew were wrong and had to be changed.
A*-1 concern Hard to think of the tests Difficult to perform procrastination.
A*-1 concern Hard to think of the tests Might be hard to think of test yourself
A*-1 concern Other. Writing code that I know is not going to work, just to pass the test.
A*-1 concern Other. Hard to think in small incremental steps
A*-1 concern Other. Will this approach work on embedded code, with hw dependencies, and on more complex problems ?
A*-1 concern Other. That you are not testing the tests well enough. And that this can cause uncertainties when debugging future failed tests. Is there a bug in the implementation or a bug in the test?
A*-1 concern Too much test code. Difficult to make interface changes without having to change the tests
A*-1 concern Too much test code. It breaks with the flow of programming & problem solving. It seems unececcary to break realively simple tasks into 100 baby steps. The test are also very narrow.
A*-1 concern Too much time. Using a debugger to develop the code would be faster. Tests could be written after.
A*-1 concern Too much time. I am curious how much time this will take in more complex code. But if this approach will give fewer bugs, I guess it will outperform the time spent on debugging.
A*-1 concern Where are the requirements? Tests can lock-in the implementation. Will it be hard to change the code if a lot of tests brake?
B**-1 concern applicable Is TDD suitable for any application / situation. For instance when code cannot be that modular.
B**-1 concern asdertyhju Building software under testing can treacherous; because it displaces thinking about state and persistence in code being written.
B**-1 concern Backwards It can be hard to figure out exactly what you have to test for.
B**-1 concern Embedded Implementation to embed. systems with spec. libraries and multitasking apps using embed. OS.
B**-1 concern Habitual Hard to break coding habits
B**-1 concern Loss of fluidity I feel like I am hopping all over the place rather than getting the job done. One line, test, one line, test, rather then getting my ideas all on the table and sorting out the problems.
B**-1 concern overlook Intentionally ignoring errors if they aren't part of the current test. Feels like I could forget to overlook something if I don't write a test for it.
B**-1 concern Practice Might take some time getting better at the process at the beginning.
B**-1 concern tests reliant Becoming too reliant on the test cases and not thinking through the code. It seems like writing the test cases takes longer than writing the code.
B**-1 concern time consuming Full-blown TDD seems inefficient and overly time consuming.
B**-1 concern unfamiliar the c++ part how does hardware fit in
B**-1 concern Untested Getting ahead of oneself by writing code that doesn't yet have a test for it
B***-10 concern Simplicity of the concepts will be lost on management. Those not understanding what it is and the potential will see it as a waste of time.
B***-10 concern It takes longer to write the code (if you don't include the time to test the code).
B***-10 concern TDD may increase the development cycle
B***-10 concern Real world problems tend to have more dependencies. What does that look like?
B***-10 concern Some steps seem too small/tedious and would be difficult to maintain TDD approach during tight schedules.
B***-10 concern The ability to automate the preconditions for a function. In case of legacy code, if the function is too long, then it will require time to understand the functionality and accordingly write the tests manually.
B***-10 concern Writing implementation just to get a test to fail/pass knowing it would be thrown away very soon.
B***-10 concern it takes discipline to NOT get ahead of yourself and start writing code that has no test
B***-10 concern It is very difficult to follow TDD from the get go. Your are drawn to complete the implementation.
B***-10 concern Integrating TDD into an existing code base. This may require refactoring which will be out of scope and management will be concerned about changing existing code.
B***-10 concern I wonder how this approach scales to a real application in terms of amount of test code to the amount of application code? Is it proportional? Is it manageable for large application?
B***-10 concern Introducing TDD to the rest of my firmware team.
B***-10 concern Quality/Code reviews should now review the quality and coverage of the tests. This seems like an additional, even if beneficial, load.
B***-10 concern Implementing temporary code that may not work if a future test is missed.
B***-10 concern If tests aren't extensive enough, could give a false sense of security
B***-10 concern Writing throw-away code.
B***-10 concern It takes discipline to execute.
B***-10 concern compiling, linking steps add too much time which I think can be unnecessary and could be easily avoided, I know I need a prototype and I can put at least a stub function to start with so I can skip initial compiling and linking errors
B***-10 concern Very different mindset than 'normal' code development.
B***-10 concern It is difficult to separate the old coding frame of mind with this new approach where you are not allowed to jump ahead and code the whole solution.
B***-10 concern Over-coding the tests which might add time rather than reduce.
B***-11 concern Burdensome Additional time in projects to write all the unit tests and legacy code not written with TDD.
B***-11 concern Culture-change TDD is a big shift from our current embedded development "culture." I have concerns about effectively introducing a process like this to my team.
B***-11 concern Dependent Still dependent on me to think of many tests.
B***-11 concern harware interface So far, it seems to be easy to test "stand alone" code, i.e. code that does not depend on hardware, or external communications, for instance. How can TDD be applied to these cases?
B***-11 concern lengthy It feels like it takes too long. I instinctively want to write more.
B***-11 concern limited identifying hard to track down integration or timing bugs that are not reproducible in a test-harness
B***-11 concern Scalability Concerns about scaling to more complex functionality and hardware integration.
B***-12 concern apply about how TDD should be applied.
B***-12 concern blind I want to use a debugger and step through my code. I can't SEE why it is failing
B***-12 concern Complexity With a more complex situation it might be difficult to accurately develop unit tests. However, if the situation is too complex that might mean the design needs rework!
B***-12 concern Comprehension It seems easy to over-focus on the tests. I ended up feeling like I didn't understand what I'd written very well.
B***-12 concern Coverage Getting the tests right seems critical. I probably overlooked something, but I got through the entire exercise without dynamically allocating the array.
B***-12 concern cumbersome Difficult for larger systems. Sometimes you don't know how the full system will look when you begin, and it can't leave even more code to refactor when you start making large changes.
B***-12 concern design how to do design? no design in TDD development?
B***-12 concern faking Getting too good at faking it
B***-12 concern implementation How to implement this in what we do at work.
B***-12 concern puzzled Integrating with components that I control. Integrating with components that are 3rd-party controlled. Integrating with system components.
B***-12 concern rework risk of not planning enough by just designing for the next test, requiring a lot of rework
B***-12 concern Security False sense of security, "All my tests pass so I must be alright!" But in reality the tests were just written poorly.
B***-12 concern slower Overall more time consuming, though bug prevention may save time in the long-run. What if a critical test condition is not thought of during development?
B***-12 concern Speed A fast build system is critical.
B***-12 concern wrong Add code that you know is wrong because the "right" behavior isn't yet needed.
B***-13 concern Does not fit how I code. How do you apply this to target hardware and external inputs?
B***-13 concern Does not fit how I code. It felt like cheating to pass the tests before a "final" implementation existed.
B***-13 concern Does not fit how I code. What if your compiler takes a *very* long time to compile?
B***-13 concern Does not fit how I code. How does this method fit in and integrate with libraries and other people's code?
B***-13 concern Does not fit how I code. There felt like there was a moment where you had to do the big refactor where it stopped being iterative, but felt like the big bang implementation that would have happened right off the bat.
B***-13 concern Does not fit how I code. Setting up the test harness to within a target environment.
B***-13 concern Does not fit how I code. Not sure how to plug-in a tdd framework in our platform (specific compilers, C-only, etc.)
B***-13 concern Hard to think of the tests Immense effort and analysis required to develop the test cases upfront
B***-13 concern Hard to think of the tests How do you figure out all the test cases? What if you don't think of a critical boundary condition?
B***-13 concern None How to jump from the mockup environment to the real HW.
B***-13 concern None It can feel like a lot of friction to do something simple.
B***-13 concern Other. Trying to compile a test that doesn't have supporting code will slow cycle time and will confound scope-aware IDEs.
B***-13 concern Other. It adds a layer of complexity that requires some understanding and skill to tackle.
B***-13 concern There is no design. Not sure how to organize/plan my own test iterations so it is as smooth as the demo was. I'm used to doing all the boundary checking at the start since those are common pitfalls which seems opposite.
B***-13 concern Too much time. It seems like a lot of time to test the basic functionality. But I understand that the tests build on each other.
B***-13 concern Where are the requirements? So far we've demonstrated that it is possible to produce failing and passing tests using brute force. I worry that we might instill a false sense of confidence by writing poorly designed tests.
B***-5 concern concern 1
B***-6 concern There is a steep self-training curve. It will take time to become second-nature.
B***-6 concern I am not used to operating in such a fine-grained way...
B***-6 concern How can I be sure that my tests cover every corner cases?
B***-6 concern Setting up more complicated tests and not being able to easily determine the condition which didn't meet expectations.
B***-6 concern May end up being time consuming and a developer or team missing their timeline.
B***-6 concern What is a good granularity level for implementing TDD effectively? How does this fit into the pure Design/modeling aspect of SW/System architecture?
B***-6 concern Like other agile type development methods, it will certainly require a bit higher overhead in the planning phase
B***-6 concern I have to get used to write tests and production code separately. It is pretty tough to me now.
B***-6 concern It's uncomfortable not implementing features until there is a test for them
B***-6 concern Dependencies on specific test frameworks. Some larger projects may have preferences for different test frameworks
B***-7 concern Why do we fake it till we make it? Why not write all your tests up-front and then write code that is going to do what you want instead of throw away "fake" code to get the magic green bar of awesomeness?
B***-7 concern Time consuming
B***-7 concern fear: I am afraid I might not correct some of the procrastination short cuts I make early on.
B***-7 concern speed: TDD might drastically slow down my coding speed
B***-7 concern INJECT:How would I go about injecting this methodology into my large code base?
B***-7 concern uneducated: I'm not sure how I'll create my test harnesses just yet
B***-7 concern Tricky: It sounds stupid, but it seems for TDD to be helpful you have to make sure you come up with good test cases and make sure they are implemented correctly. Writing good test cases seems like another skill to develop
B***-7 concern Maintenance: It seems easy for older tests that previously passed to fail in the future after functions have been fully written and values are no longer being hardcoded.
B***-7 concern coupled: How to use it in larger contexts or when the module is highly coupled
B***-7 concern diligence: My initial concerns are that if I get lazy about being diligent with TDD I will leave hard-coded or incomplete code in my functions.
B***-7 concern a lot of test but the real work is not done!
B***-7 concern Incorrect: Incorrect tests may mean you have to rethink the design and redo the implementation. How do we know if our tests are any good?
B***-7 concern right tools for embedded system; work load;
B***-7 concern Unfamiliar: The disconnect in thinking. Instead of focusing on solely developing, it seems that the process is a time-drain. But I know this is only at the start, since this will save time at the much later stage of debugging.
B***-7 concern integrate: How to integrate to my tool suite and my target hardware.
B***-7 concern Tedious: It can sometimes feel a bit tedious to create tests before writing code.
B***-7 concern MISRA: Dynamic memory allocation is often a NO-NO in the embedded world, especially if you follow any standards such as MISRA. How to do TDD and be compliant?
B***-7 concern over-thinking: By over-thinking while programming, I might miss some test cases. How could I make sure the test cases are developed from simple to complex?
B***-7 concern Need a lots test cases that actually sometimes is more complicated than direct logic programming. For example, we created a large fixed size buffer. After design about more than 10 test cases, we still have everything passed. This could indicate that if we don't design right from the beginning, if the programmer is not good at test case design (many of them not since test is reverse logic to develop logic in certain way), then some bugs might be hidden.
B***-7 concern Over-confidence: My concern is that developers could rely too much on the test cases. If important test are missing, incomplete, or inadequate, then bad code can get through the system.
B***-7 concern Need maintain a big test code. Gradually the developer doesn't want to change any requirements since one change might break many test cases.
B***-7 concern faking: Im concerned there is a lot of focus on just "passing the test" without actually understanding what functionality you really should be implementing. I like stubs and placeholders but it seems like you can take "fake it till you make it" a bit too far
B***-8 concern covering all test cases
B***-8 concern adapting to legacy code
B***-8 concern In order to come up with a reasonable list of tests you have to have a good understanding of how the feature works in the first place.
B***-8 concern That I might not think of a necessary test case
B***-8 concern can lead to writing code without a good plan or design
B***-8 concern If the test list not completed, the code may not either.
B***-8 concern I am concerned that coding up tests will add to the budget and schedule of a project. The code for the tests can also be a source of bugs.
B***-8 concern How should I test hardware-specific testing (such as writing/reading to EEPROM, hardware timers, etc).
B***-9 concern Had to leave immediately inclinations and insights out of code unless you were testing for it at that moment. A lot of "creative" impulses/insights were dropped on the floor.
B***-9 concern I might go into the abyss of trying to test absolutely everything.
B***-9 concern It isn't always clear to me "what the next logical test is" but I think it's a learned skill.
B***-9 concern can be time-consuming and a little bit repetitive. need to find the step size I'm comfortable with
B***-9 concern for larger, more complex systems, how do you know when enough is enough? Where do you draw the line?
B***-9 concern How do I explain to my boss, who is stuck in the waterfall world that this will help, and improve the current workflow?
B***-9 concern Nothing is free... building that test suite does take a long time; in fact it seems to me that at least for the example it takes about twice as long to write as the actual code.
B***-9 concern How am I going to implement this on my system without a herculean effort?
B***-9 concern It takes some conscious thought to adopt it truly, but I'm hoping that once it's a habit, I will be able to adhere to it with less effort.
B***-9 concern Adoption. I've already faced some resistance from colleagues regarding the practice. Once the habit is formed it doesn't feel like extra work, but initial adoption may be difficult for some.
B***-9 concern Still unsure how to apply to some embedded specific scenarios when hardware peripherals enter the equation.
B***-9 concern A long list of tests is going to get complicated. I need to figure out how to organize them.
B***-9 concern Need to better understand the relationship between extra time spent doing TDD vs. time saved later. The final product should be TDD'ed, but what about all the one-offs that are created and then scrapped very fast? I think gaining more architectural experience should help with this concern.
B***-9 concern Effectiveness is still a function of programmer discipline/foresight. Tests only catch what you thought to test.
B**-1 concern Contrived nature
B**-1 concern NA
B**-1 concern Sometimes hard to not over-design while writing tests. Hard balance.
B**-1 concern N/A
B**-1 concern Seems to be more focused on newer developers rather than experienced developers.
B**-1 concern nothing
B**-1 concern how it is applied in real development cycle?
B**-1 concern Some of our developers will not see the benefit of TDD
B**-1 concern maintenance cost when code changes
B**-1 concern It seems to focus on small details of a programming problem without thinking broadly about the design first. This could cause us to push design decisions down the road where they may be forgotten.
B**-1 concern Assumes no timing dependencies with HW.
B**-1 concern TDD seems great for new code, but how will this work with a large amount of legacy code that doesn't have tests available. Seems like TDD will be used for new, but legacy will be left alone.
B**-1 concern I agree with adding functionality incrementally, I don't agree with intentionally adding incorrect functionality. Need to be be practical about what is added in each step.
B**-1 concern red-green refactor takes discipline
B**-1 concern if the process is too verbose, it might allow for people to inject their own "style" into the tests. Is this bad? I don't know, but it seems like it might be a concern.
B**-1 concern What happens if a previous test passes when it should have failed? Where would the error get caught?
B**-1 concern Our compile time is much longer. The multiple compiles with small changes will be very time consuming. Baxter may need to get leading edge PCs for engineering instead of barely acceptable.
B**-1 concern It could slow down development
B**-1 concern Takes longer to develop because your doing two activities at same time.
B**-1 concern Some developers will think it takes too much time away from writing code.
B*-1 concern Sometimes impractical for things like algorithm development (but not always).
B*-1 concern It's hard to not think ahead past the next smallest chunk
B*-1 concern end up with more refactoring then would if looking at all requirements right away
B*-1 concern Overall architecture is not the focus. I tend to think in OO and flexible designs rather than functionally decomposed pieces of code.
B*-1 concern Originally concerned that tdd would add too much time to the development process.
B*-1 concern Pressure on to write test first before we even write the code
B*-1 concern I find that it short-circuits or slows down my mental processes in creating an algorithm.
B*-1 concern Time consuming
B*-1 concern does not cover requirements analysis, maybe it is not in the scope of TDD.
B*-1 concern Designs were scoped too narrowly at first, requiring frequent refactoring.
B*-1 concern Moving an existing code base to TDD
B*-1 concern The build errors could be avoided using VS.
B*-1 concern Give me the keyboard ... a.k.a. hold my beer watch me do this. Rules must be placed before hand How do you start on an existing codebase, especially when written by others (without TDD in mind)
B*-1 concern 1. Upfront investment time.
B*-1 concern Causes more compile time. Sometimes on focussing on too small of a task might make you see the big picture.
B*-1 concern Inefficient. Rewards incremental short-term hacks over a comprehensive solution that makes all tests pass. Refactoring for each test wastes time.
B*-1 concern It seems to get a bit tedious when you're constantly approaching a problem incrementally in rapid succession like the exercise. It seems like you do have to fight a bit of a natural urge to hash out your entire solution and instead approach things incrementally.
B*-1 concern Initial time spent on TDD. Sometimes minimizes lot of unit tests, but some time doesn't
B*-1 concern the acronym might be confused with telecommunication device for the deaf
B*-1 concern I'm not convinced developing one case at a time will yield maintainable code.
B*-1 concern After 35 years of development, it is not how my brain works.Normally would attack the issue with the BIG picture in mind, not a myopic view and build from there.
B*-1 concern writing test cases between components
B*-1 concern sometimes keeps you from thinking about the bigger picture
B***-1 concern ??? don't know
B***-1 concern forget Forgetting a test case and, therefore, forgetting to properly implement a function with a "return true" type of temporary implementation.
B***-1 concern Irritating Allowing compiler/linker errors that you know are going to happen doesn't seem like it adds a lot of value.
B***-1 concern none Nothing yet.
B***-1 concern obstacle dependencies and coupling
B***-1 concern Portability Portability.
B***-1 concern Redundancy The approach being taken in the exercise seems to result in a lot of redundant code being written to simply satisfy test cases when implementing features in a different order would have removed that
B***-1 concern schedule how to add this type of testing without impacting overall schedule
B***-1 concern slow It will slow me down when coding. Not used to writing test before implementation.
B***-1 concern Test bugs We can write bugs in the test cases.
B***-1 concern nothing
B***-1 concern Getting ahead of myself
B***-1 concern How to apply to existing project(s).
B***-1 concern With TDD being so involved, I wonder how much additional time it takes to get to reach a minimum viable product compared to other methods.
B***-1 concern I find myself thinking about how it relates to software tasks that involve complex inputs & outputs (say a DSP filter implementation).
B***-1 concern False sense of confidence that the tests will prevent all bugs.
B***-1 concern Difficult to determine how much TDD will impact schedule via additional steps. May have positive impact, may not.
B***-1 concern What if I'm not writing correct tests?
B***-1 concern It will be interesting to see the approach to TDD in an environment without the actual hardware where the hardware would presumably be actively changing values/circumstances to which the software would need to react.
B***-1 concern It seems like it is very complicated to ensure that your test cases actually cover all uses.
B***-1 concern It may be difficult to ensure a team follows TDD if management is not fully on board.
B***-1 concern TDD has to be added to product cost.
B***-1 concern It encourages writing poor, broken implementations, if only temporarily.
B***-1 concern Justifying to others the extra effort for developing the tests.
B***-1 concern Requires developer to keep track of the "fake" implementation to go back and fix. Is it possible to miss that later on because all the tests are passing?
B***-1 concern It seems easy to write tests that become a maintenance burden.
B***-1 concern It seems really easy to miss things when "just making the test pass"
B***-1 concern As with any methodology, it is easy to follow the rules of the doctrine and not end up following the spirit of the law. Easy to get hung up on 'what should I fake, what should I not fake,' and the flow chart therein. Really the decision is more sensitive, and boils down to experience as a developer.
B***-1 concern The value of this depends heavily on a quick turnaround time of compiling, linking, and running the tests. For an environment with a long setup time, or a lot of moving parts which aren't precompiled and then linked in, this would doom you to spend the vast majority of your time watching the build and setup before getting value. It also felt like a big impediment to do things in tiny steps. Like purposely tying your shoelaces together. If one were lost in the woods, and obliged to take baby steps, maybe this would give you time to think things through as you wait for feedback. If you do know what you're doing, this is a giant speed bump. I am concerned that for policy makers who are attracted to fads and management by cliche or sound-bite, that this would be instituted as a requirement to slow everything down and wreck productivity. If it is clear that this is one more tool in the toolbox, and we should use the right tool for the right job, then it certainly has its place. While it's early in the class, it hasn't yet been called out that unit tests are different from integration and systems tests, and this may not be appropriate for all of them.
B***-1 concern lack of general focus on design from the start, which could help prevent unnecessary refactors halfway through
B***-1 concern I don't feel like we thought about edge cases much in this example
B***-1 concern There is a lot of mental context-switching in and out of the production code when writing the tests. Does that make it more difficult to come up with wholistic, well-architected code?
B***-1 concern It seems pretty easy to accidentally test the wrong thing. We pair-programmed the tests and both of us caught the other one putting in bad test expectations (particularly getting the sense of a boolean backwards). In most cases this was caught by a failing test but it's possible to make the same mistake in both the code-under-test and the test case.
B***-1 concern It feels like more brain power is required to follow this approach as opposed to fully implementing a function before test.
B***-1 concern The negative of the "fake it 'till you make it" approach is that you have this internal doubt about the quality or accuracy of your code at any point along the way. Thoughts arise: Is your code actually doing the right thing? Are you testing the right things? Are my tests passing due to false-positives?
B***-1 concern seems like you would want to completely write an entire function and all tests for it before moving on to the next function, as opposed to getting a "minimum viable product" via tests. This makes it hard to determine where the bugs actually are, which seems like the opposite of what TDD is supposed to provide.
B***-1 concern It's really hard to hold myself back from writing more code than is necessary.
B***-1 concern I am a bit concerned that designs and interfaces may change late in the process because not a lot of forethought was put into the initial design (i.e. having to add the default circular buffer value near the end of the exercise)
B***-1 concern Forgetting about hard-coded values -- discovering bugs after I hand it to the customer, if they use the interface in a different way.
B***-1 concern Tests passing by side effect (hard-coding initial values).
B***-1 concern Possibly introducing bugs as you write the most simple implementation code to pass the unit tests and not remembering to add additional tests to cover the bug you added.
B***-1 concern I am concerned about how to know you are writing the tests themselves correctly and how to ensure the tests adequately and correctly cover your requirements.
B***-1 concern "Fake it till you make it" caused LOTS of re-write. Sometimes we could trivially "see the re-write coming", and it felt like delaying it just made it harder when it finally hit.
B***-1 concern * Because it forces one to externalize processes we internalized yonks ago, it is easy to get ahead of one's self. * It can get tedious forcing one's self to take baby steps.
B***-1 concern My co-workers will feel like they (or I) spend entirely too much testing instead of working.
B***-1 concern TDD is great as a development methodology. But to get it right, the developer needs a firm grasp of design and test methodologies. Design methodology to identify what one is trying to solve and at a high-level how, so that this can inform the TDD test cases. Test methodology, to anticipate how code is likely to fail and how to test efficiently (i.e. not create overly complex or unnecessary tests).
B***-1 concern CppUTest seems to execute tests in reverse order, so the first test to fail is a complex or subtle one, not one of the very simple tests that I wrote first.
B***-1 concern Don't immediately see how this would be applied to lowest-level code (directly dealing with hardware peripherals with on-read/on-write behaviors, ISRs, DMA, etc).
B***-1 concern might have too many tests that are so simple, they are useless to the end product, then having to fix them
B***-1 concern Implementing DRY in unit test code. Refactoring unit test code making the test code possibly harder to understand. “DRY in particular I don’t subscribe to for test code, because I want my tests to read like a story.” - Kent Beck
B***-1 concern Use invalid assumptions (intentionally) in some of the test designs. Need discipline to go back to undo/correct invalid assumptions. I am concerned that I would forget an assumption and leaving an assumption in place. (It's the 7 +/- 2 short-term memory issues.)
B***-1 concern I'm not sure how scalable this approach would be to a huge system. The answer may be that the test cases would not have the same level of granularity as the ones from this exercise.
B***-1 concern I am used to consider a problem in whole and not in pieces. TDD seems to perform localized optimization to generate tests. I am more used to solving a problem in whole. TDD is a new mind set that I will need to get used to. I can see some benefit to incorporate some of the concepts and approaches into what I am doing today.
B***-1 concern Not having an automated test runner within an IDE reducing the feedback loop time.
B***-2 concern badger It breaks up my global train of thought when making such small code increments.
B***-2 concern context switching Context switching when "cheat". I.e. thinking about empty, cheat, move on to full
B***-2 concern corner cases How do I know I get all the corner cases (by going step by step, I might miss the big picture).
B***-2 concern counterintuitive That you have to work against your instincts when writing your implementation. That it took us 90 minutes to write something that is normally a 15 minute interview question.
B***-2 concern Experience Nothing so far. Perhaps the decision as to when in the process to procrastinate and when to implement is a matter of experience.
B***-2 concern greedy It's kind of a greedy algorithm, fear that might end up in a complex place with lots of cheats rather than incrementally getting closer to end goal
B***-2 concern I'm Crazy How does TDD work with techniques like "Property Based Testing"? Can they be combined?
B***-2 concern procrastination Getting the experience to figure out when to drive toward a solution or delaying implementation.
B***-2 concern Time consuming It seems time consuming for the real world to go step by step, instead of creating tests based on the expected behavior... and then testing against code (other implemented or later implemented)
C*****-1 concern Feels somewhat slower than writing tests at the end (but then again, there's little to no debugging at the end)
C*****-1 concern The complexity level of the code at the end of the exercise was higher than I would expect.
C*****-1 concern I'm worried we will get impatient and cut corners (like Sergey was doing)
C*****-1 concern i don't know how to handle the 'test the tests' problem (my day to day work is standing up systems and coding tests) in other words, how do I apply this to complex testing?
C*****-1 concern Developing code in very small chunks slows me down
C*****-1 concern no concerns yet
C*****-1 concern It will be a big change of thinking, so there may be pressure to "just get my job done".
C*****-1 concern How do I know when I've tested enough? How to avoid getting the implementation ahead of the tests (I have a tendency to develop more than the tests require)?
C*****-1 concern Working in some build environments, the rapid cycle of TDD might be hard to achieve. When the compile, build, or run time takes > 30 seconds, stopping to check that the missing header is detected, and similar steps, while providing some value, would seem to take up several minutes per line of real code written.
C*****-1 concern over analyzing the test itself. Is this too small, too big, am i doing it all wrong and hurting myself more than helping myself.
C*****-1 concern doing just enough to pass the test is fine but what about secure or portable code?
C*****-1 concern I'm surprised to see the return of fake values, and so on as this seems to be deliberately creating bugs in order to stimulate a bug hunt. E.g. I hope we find them all.
C*****-1 concern So far I'm wondering how this will play out in our environment. I also feel as though this requires a certain level of knowledge that my more junior engineers might struggle with
C*****-2 concern bad example The example (circular buffer) was much too simple to be instructive. It's too easy to "game" the tests: write things that are known to be wrong, just to pass the test.
C*****-2 concern busy work Testing the test meant writing bad code just to make the test fail first. This led to some confusion as to where I was in the process: still making and verifying the test fails, or trying to fix it?
C*****-2 concern confusion Writing code that passes tests but is obviously not going to do what we want. You end up with a bunch of code that doesn't work.
C*****-2 concern design im worried that designing things for the short term will have large negative consequences later on
C*****-2 concern Enumerate tests At what point do we enumerate all the tests you want to write. It felt to me, that would be good to take a first stab at enumerating the unit-tests before writing the first one.
C*****-2 concern expectations Trying to figure out what to test before you have a clear idea what you want.
C*****-2 concern fake until you make At least in the first few tests, "the fake until you make it" approach seemed a lot of throw-away work.
C*****-2 concern Frustrating In the exercise, I wrote myself into a corner. I did not consider wrap around until I got to those test cases. I wish I had considered it from the beginning.
C*****-2 concern legacy Integrating the concepts into our legacy codebase.
C*****-2 concern overhead It seems that the overhead of intentionally failing one test at a time is very high. It seem like it would be much more efficient to work towards a few tests at a time and not intentionally fail them.
C*****-2 concern retrofitting Retrofitting legacy code seems like it would be overwhelming.
C*****-2 concern unnatural It feels 'fake' to have to write intermediate 'dummy' code/steps that you know are not going to cut it
C*****-2 concern wonder it can be difficult to find out how low you can go, e.g. I made a change at one point that made a couple of the subsequent tests work, which I guess was not supposed to happen
C**-1 concern approval from others Spending too much time on code development because of TDD and then having to justify this time to my managers - it's hard when I don't even believe that pure TDD is necessary.
C**-1 concern bad enfluence encourages bad development practices
C**-1 concern boundary Some boundary conditions are implementation specific, so hard to write test in advance.
C**-1 concern cumbersome In a deadline, i can see this process to be cumbersome to manage.
C**-1 concern dependencies My concern is how to handle Hardware dependencies.
C**-1 concern dependency Can't see a downside for the moment, but it looks like it tends to make the developer to rely heavily on the tests
C**-1 concern distracting Can be difficult to focus on good design/good refactoring
C**-1 concern effort Concern that the additional up-front development effort could be significant
C**-1 concern granularity Doing this iterative test and development at very low granularity can be conterproductive.
C**-1 concern hurdle These tests are useful for a win32 platform. When it comes to putting these in place for our dsp platform, which has a different compiler, data types and architecture, the workflow is not trivial.
C**-1 concern incorrect testing My test script for testing the code may be wrong and misleading
C**-1 concern infeasible Too structured and not that practical in a deadline driven work environment.
C**-1 concern Interface Usually we lock down the interface so others can use it, this TDD approach keeps the interface in flux
C**-1 concern lazy it is OK to be a 'lazy' programmer, and procrastinate until you are forced to. If you run out of time, you're left with unfinished work.
C**-1 concern Linear I'd rather work on one function at at time, however TDD could be applied to this approach too.
C**-1 concern long process long repeated procedure breaks my flow of ideas on how the pieces are put together on the module I'm developing
C**-1 concern maintainability There is a maintenance cost for the tests. It seems possible that the volume of test code might eventually exceed that of the production code.
C**-1 concern not Somebody will think that is a method to fit all use-cases.
C**-1 concern progress-ish? it can feel like you are making good progress when you are may actually not be developing much useful functionality.
C**-1 concern Short-cuts Easy to short cut the steps by knowing where you want to get to and doing many steps at once.
C**-1 concern Slow Very time consuming. Baby steps not often appropriate for fast development cycles. Antagonistic to requirements driven development as dictated by many outfits.
C**-1 concern Stubs Stubbing production code to make tests pass allows these stubs to be deployed if missed by peer review. I'd rather see tests failing until production code functions are implemented.
C**-1 concern tedious very long and tedious development process, sometimes I feel like I've lost sense of direction of where the end product should look and behave like
C**-1 concern testing testing Gives fake sense of achievement by writing tests that fail, then making them pass, doing some development on the way. But the actual activity feels a lot like we are developing tests, not a code
C**-1 concern Tideous Sometimes we could end up spending lot of time in writing the tests and making sure that valid use cases are tested and is driving towards the end product.
C***-1 concern - The time it takes to add test coverage. It will definitely take longer upfront, but I think it'll save time later. - How to cover some testing, like when actual hardware is needed because of variance in it.
C***-1 concern You can get so involved in the test of the code that you don't actually get to finish the code
C***-1 concern Lots of code for test. Lots of design of test. Makes my interfaces even harder to change.
C***-1 concern Right now, it seems tedious.
C***-1 concern I'm skeptical of TDD's ability to cover low-level, hardware-interfacing code without some sort of sophisticated emulator.
C***-1 concern Coming from my current way of programming, I find myself jumping the gun on implementing things that are not tested yet. (It is hard to fake-it to make-it.)
C***-1 concern It can be hard to adhere to, but that may just be from lack of practice at this point. I feel like I can get really bogged down satisfying the granularity of it. Again, probably from a lack of practice.
C***-1 concern It slows you down by requiring incomplete implementations, making the development process iterative and incremental. It introduces bugs that you are supposed to discover later.
C***-1 concern Will tests be maintained over time as the code is worked on by different developers
C***-1 concern I need lots of practice to keep the little steps as my mind tries to resolve more at the same time so I have to back off.
C***-1 concern As a beginner, It can be easy to get ahead of yourself. Sometimes struggling to decide what's next. (Again, beginner issue)
C***-1 concern The test may not have a good or precise coverage In some situation, code may not be easily tested such as human interaction with computer
C***-1 concern deciding what to test
C****-15 concern breaking up of the functionality into smaller tasks/UTs
C****-15 concern No concern.
C****-15 concern disruption to developer's productivity
C****-15 concern I'm concern that i'm not going to get a full value of this course. the programming aspect is difficult. I believe it could be written or design not to be difficult for a broader audience.
C****-15 concern Proper frameworks, constant data dependencies, maintenance and times to execute the tests
C****-15 concern Maybe the editor used for the exercise..:)
C****-15 concern x
C****-19 concern Not yet convinced about the virtue of always writing functions like "return 42"
C****-19 concern sometimes it could be time consuming to write test upfront. particularly in a multiple component code base, you have to do lots of mocks.
C****-19 concern TDD from scratch seems easy enough, but applying it to a legacy code base still seems scary (I know, that will come later...)
C****-19 concern feels odd to be writing code just to make the test pass, when we know that it won't work (e.g. hardcoding values)
C****-19 concern Is it that easy with more complex code?
C****-19 concern Makes a lot of sense for a 'unit', not yet clear how this applies to partially or fully integrated code.
C****-19 concern Not much worrying about full picture could potentially result in huge amount of refactors over the period of time (may be not as evil as it sounds)
C****-19 concern tdd is working great when we're dealing with simple one module, but what if we have to create a system with many modules and half way there we realise that our architecture was wrong or requirements change and we have to reorganize the modules (split them, combine them or change dependencies) - then we will have to rewrite not just a lot of code but also a lot of test code and unit tests won't protect us from regressions when we reorganize the modules
C****-19 concern can it make the development _much_ slower? (of course with the other benefits)
C****-19 concern Seems to discourage up-front design, e.g. making up API on the fly. This may also not work well in 'real world' where sometimes API must be agreed up front.
C****-19 concern If I miss one test it probably means one bug in the code.
C****-19 concern At what stage do we think about an overall design for the implementation? Will we get a performant implementation, for example, just from TDD? We might have a functionally complete and corrcet implementation, that then fails performance tests we add at the end - leading to a re-write of the implementation. Is this a risk? How to we avoid it?
C****-19 concern how does TDD cope with complex classes? (can you always split them?)
C****-19 concern Time taken to go through the many small cycles.
C****-19 concern it's nice and easy when our module that we're testing doesn't depend on anything, but there might be a lot of work when trying to do tdd on modules that depend on a lot of other modules - we will need to create mocks for them and this might mean a lot of work upfront before we write any code for our module
C****-19 concern Coding will be slower as we do more steps.
C****-19 concern how does this scale to systems without a fast build/run-test cycle?
C****-19 concern How to convince others of the importance of testing: i.e. do I need to write a test for such a small change?
C****-21 concern Afraid that we might end up focussing on just get the test cases pass.
C****-21 concern Seems waste some early code. As the it develops, need to change the function contents.
C****-21 concern If anything concerns me it's that I might use the testing to drive my development right into a hole and have a hard time backtracking in order to get out of said hole.
C****-21 concern 1. It feels like a lot of overhead for implementing simple features. 2. I have to hold back on ideas.
C****-21 concern Takes more time to finish a given task.
C****-21 concern Is this method difficult to follow with more complex designs?
C****-21 concern is it scalable to any kind of development activity.
C****-21 concern How to run the regression test suite of 1000 TC.
C****-22 concern - concurrency is hard to test in TDD - mocking the "rest of the system" can be long, tedious and prone to bugs...
C****-22 concern Scaleability - Editing lots of small tests when API's change
C****-22 concern more rework, increasing the work de-satisfaction.,
C****-22 concern * The fact the we start with failed test :). * When I made implementation only as much I test it and not considering many scenarios, it concerns me that I might miss some conditions. * It might take some time to get used to writing test fail and then correct it.
C****-22 concern may have more duplicated tests.
C****-22 concern TDD test cases should be written from another team member, which generally does not happen in practical scenarios....
C****-22 concern - how to apply this in the real world where you are constantly under pressure to show progress and tdd seems to have a initial slower progress than if I say to my boss "I am code complete now I need to write the test" - how to apply when you are extending existing code which is huge and badly written and has no infrastructure for TDD?
C****-22 concern Most of the time, development code gets followed by unit test (whether TDD, BDD, etc)....
C****-22 concern Difficult to decide how much to cover about the code.
C****-23 concern Still unsure about how to best stub out hardware dependency.
C****-23 concern It is tempting to not stick to it
C****-23 concern Works fine when starting to write a module from scratch but what about legacy code?
C****-23 concern Granularity of tests (i.e. how basic should the test be) - too basic tests feels like churn)
C****-23 concern Tests passing on the first try may give a false sense of correctness.
C****-23 concern When doing modifications on bits in a big code base, it can be hard to get code under tests.
C****-23 concern The number of test cases seems to grow at a higher rate than the added functionality.
C****-23 concern A feeling that it "dumbs down" sw development process
C****-23 concern The urge to implement all the "easy" stuff before adding enough tests.
C****-23 concern The test code can easily exceed the code you are testing by a very large factor
C****-23 concern We are leaving quite a lot of code behind during the first tests that we know must be fixed later on. So when we end up having to do the actual work, the task might become quite large to get all the previous tests to work.
C****-23 concern Might be a bit extensive when you're prototyping some ideas.
C****-23 concern How to make test for quality issues on e.g. audio or video
C****-23 concern Possibly: Maintenance of test code
C****-23 concern Initial progress feels slow (mostly because tests don't feel like the "real" output)
C****-23 concern Unit tests might be fairly expensive in production code - not sure how to argue for letting many new tests pass code review in those cases.
C****-23 concern Accurately mocking real hardware and get the behaviour wrong
C****-23 concern When you don't even know beforehand that you're sw solution is going to work, it is easy to fall back to "test-after" after writing some hack code to test the viability of the solution.
C****-23 concern If you write too many tests and too many functions in the production code that you know is hard-coded to make the test pass, it may be hard to refactor the production code afterwards. In our example - when should we start concerning about wrapping
C****-24 concern Issue is how this is going to fit in our real product scenario where the compilation takes more time and doing this incrementally might be painful
C****-24 concern Appears to be a slow process of development. Can we skip some intermediate steps?
C****-24 concern If we are writing our own new file, going with TDD approach might be easier. Doing this with already existing code it might be tricky
C****-24 concern Completeness of your code depends on the completeness of your tests. How to generate all possible test cases?
C****-24 concern Not sure if it impacts the development time.
C****-24 concern Compilation time for the legacy code that I am making modifications to.
C****-24 concern Adding logic when required can make earlier tests fail. We need to go back through the earlier cases, and correct them to suite the new logic. Seems to be an overhead.
C****-24 concern Is there any order in which the tests should be written, that way you minimize changing the previous tests when new logic is added?
C****-24 concern What if code-to-compilation-to-run path is not so quick?
C****-25 concern All the above. Could write some code for a test to pass in a simplistic way, forget about simplification and leave it there.
C****-25 concern Does not fit how I code. not really sure how to apply it in a large project with multiple actors and complex distributed data...
C****-25 concern Does not fit how I code. Simultaneously coding and testing means an interface change may propagate and break prior tests before the final product. What is a good granularity for this?
C****-25 concern Does not fit how I code. I like putting a scratch-pad like implementation to test the concept first so I don't know the final functionality or code structure initially.
C****-25 concern Hard to think of the tests Incomplete production code/HardcodecodedValued might be forgotten if the tests are not good enough. I now have to worry about test code and production code :)
C****-25 concern Hard to think of the tests What if I forget to test something not so obvious?
C****-25 concern None None.
C****-25 concern None none
C****-25 concern Other. Writing code with minimum needed to pass the test (e.g. return 42) has the downside that if one forgets to test a certain behavior, code will stay wrong.
C****-25 concern Other. You must employ tools to cover all potential bugs strictly related to the implementation. I see TDD checks adherence to requirements but can't give any guarantee on the quality of the implementation.
C****-25 concern Other. it can happen that we develop the tests that might not catch bugs introduced in step by step approach concerned how it fits in more complex projects
C****-25 concern Other. What's the test completion criteria? How to identify test gaps?
C****-25 concern There is no design. I could "overfit" and "cheat" and make tests pass even if my implementation is a hack
C****-25 concern There is no design. Lack of global view we are sometimes too focused on the specific piece we are implementing and we should step back to reconsider the overall design
C****-25 concern There is no design. Perhaps by focusing on having each individual test passing, I forget about the bigger picture and how my overall design can be optimized.
C****-25 concern There is no design. It doesn't have design/architecture approach in the process. Having the test passing doesnt mean that the implementation is optimal.
C****-25 concern There is no design. If a test case is missing, we will miss the code for a use case.
C****-25 concern There is no design. Can lead us into a false sense of security: just because the tests pass, doesn't mean we can skip the design phase.
C****-25 concern There is no design. TDD is not separating requirement from implementation testing.
C****-25 concern Too much test code. Strong coupling to the APIs. Changing an internal API means changing the places where it is used, including the tests. Even more, changing the logic of the test may be needed.
C****-25 concern Too much time. It takes longer than coding and then testing. We keep rewriting the same code over and over.
C****-25 concern Too much time. Would it work the same in big projects with different modules and complicated interactions and a very badly designed system where nothing is stateless? (Without sacrificing execution speed)
C****-25 concern Too much time. It makes you avoid writing the final "correct" solution by introducing fake input. If this is not fixed and tested later it might introduce bugs. It takes more time.
C**-1 concern Does not fit how I code. It might be difficult to always think of the all tests required before developing the software.
C**-1 concern Hard to think of the tests Coming up with the test and their orders can be the more challenging part. Poorly designed tests can lead to a terrible implementation flow
C**-1 concern None making small changes that seems obvious makes you think you are going slower.
C**-1 concern Too much time. Sometimes looking into smaller requirements is undoing and redoing things also have to forcefully break the train of thoughts. Breaking into smaller steps for a bigger project may be challenge.
C**-1 concern Where are the requirements? I was little lost at the start without requirements
C**-1 concern Where are the requirements? Requires different design and development approach compared traditional when when have all the requirements up front
C**-1 concern Doing "just enough" to pass the tests results in writing code that might not comply with the design for this module
C**-1 concern Leaving garbage code in product because the tests weren't comprehensive enough (i.e. I missed something).
C**-1 concern The amount of time it takes to create a test for a simple scenario...how does this scale to large scale deployment
C**-1 concern Writing sufficient tests for complex code, which depends on many inputs some of may come in different orders.
C**-1 concern - Time consuming to update all tests if API changes frequently - lots of little test when they can be grouped together - the process is just too iterative; step of adding hard-coded values can probably be avoided, -steps to just make the test pass somehow in first go and then coding it properly later can probably be avoided...
C**-1 concern how it can be used in my work
C**-1 concern How many tests would need to be created for a large scale system
C**-1 concern Write-Compile-Test cycle taking too long because the compilation takes too long.
C**-1 concern How it is introduced in legacy code.
C**-1 concern I am not sure how well it will apply to code that has a lot of dependencies with other modules
C**-1 concern Potentially time consuming but possibly 'cheaper' than debugging after the fact.
C**-1 concern I can see how it will work on small amount of code but not sure how it will work on a large scale.
C**-1 concern i am afraid that it may not be practical with certain code bases, where there are several very large functions with up to 20 input parameters, and where the function derive inputs from several sources (e.g. hardware). The input/output parameters are also no nice and neat integers, they are often noise like random signals. It would be difficult to determine the pass criteria without analysis using a higher level programming language like matlab or python
C**-1 concern Quality and useability of the test framework is likely to be an issue
C**-1 concern slower development working with legacy code spoofed fixed values that could get forgotten about
C**-2 concern I am finding the partial implementation of a design frustrating, in particular leaving obviously broken code in place just because it is not yet tested. I would need to find for myself a better way to track what tests are missing that match the areas of the implementation that I know to be wrong or missing
C**-2 concern Implementing the initial code knowing it will not form the final solution. What is the cost in implementation time of this approach ?
C**-2 concern Seems bit slow and the affect it may have in delivering new functionality to customer. Ofcourse it may get compensated that you have to debug less but as a company we rely on delivering new functionality as early as possible in market.
C**-2 concern I can't see how it applies to large legacy functions where for example you may need to change 3 or 4 lines scattered around in a 200-line function.
C**-2 concern It's very, very sloooooooow
C**-2 concern It involves a lot of unnecessary rework
C**-2 concern * We ended up actually writing code we knew was broken, which meant there was a LOT of refactoring. * In the case where the testcases can't be written, e.g. concurrent code, we could end up going down a rabbit hole.
C**-2 concern time consuming and worried that this will be put to one side when pressure is on
C**-2 concern Nothing much at the moment.
C**-2 concern Initial setup/framework cost
C**-2 concern thinking in a different way, the example requires rework and throw away work en route
C**-2 concern Seem to be too time consuming
C**-2 concern not sure of the applicability wrt legacy code
C**-2 concern Need to speed up
C**-3 concern Hard not to leap ahead.
C**-3 concern Our code base is going to increase in size by a factor of 10!
C**-3 concern Not sure there is 'buy-in' from the company
C**-3 concern Reworking/refactoring the code written to just make previous tests pass.
C**-3 concern Task duration estimation.
C**-3 concern 1) Maintenance cost 2) Retrofitting it to existing code cost (worth it?) 3) Higher initial development cost. (trade off with better code presumably worth it)
C**-3 concern Loosing track of what you were planning to do (algorithm, corner case)
C**-3 concern The methodology required fast compile/link/exectute environments. May not be quite so efficient for testing functionality that is very dependent on target hardware/environment. With more involved test cases, test case maintainance may be onerous.
C**-3 concern The additional time to be allocated by project management in the development cycle,
C**-3 concern Testing a function Sqrt(x) will require an infinite number of test cases.
C**-3 concern Overhead of implementing test case (and proving that it works correctly) can be somewhat laborious. (at least is the example just completed where the code behaviour is relatively simple)
C**-3 concern - How to apply it to complex functions, or, for instance, signal processing functions.., would I need to have some kind of prestored pattern to check against?
C**-3 concern - Sounds Time consuming - Apparently same person doing development and testing details, so more time required.
C**-3 concern Is the test correct?
C**-3 concern Works for simple functionality but not sure for complex cases.
C**-3 concern - How to manage large quantities of input parameters and how to be sure the coverage is good.
C**-3 concern - Tricky to keep testing ahead of implementation and not the other way around.
C**-3 concern It doesn't drive to efficient implementation - rather functional completeness against the tests written.
C**-3 concern Forgetting something that has been 'bodged' but releasing it anyway.
C***-1 concern bugs in test code?
C***-1 concern proclastination
C***-1 concern Will there be enough time to cover all aspect?
C***-1 concern More work will be needed for current development.
C***-1 concern Creates a snowball effect of coding, the more tests you write the more you have to go back and implement more features instead of implementing as you go.
C***-1 concern Kept me from thinking about the design up front.
C***-1 concern Hard to use if there as several people developing the same feature.
C***-1 concern No step in the process to review the algorithm. Just make tests pass.
C***-1 concern please explain details on objective and outcome
C***-1 concern How can you test for code performance
C***-1 concern I am not able to get exact advantage of 'Fail' first before 'Pass'.
C***-1 concern TDD works better only when the Test cases are written properly. It might lead to miss the bigger picture . Not similar to traditional programming .So may lead to confusion and less productivity at-least initially.
C***-1 concern When a change caused multiple tests to fails, we had to make many changes at once to fix it. Since we never really thought about the algorithm, this led to some thrashing.
C***-1 concern My brain isn't wired to think of tests. I think in algorithms.
C***-1 concern Possible lengthening of devel time if followed too religiously.
C***-1 concern Leaving the test codes in production code such as hard coded values
C***-2 concern TDD appears to only be as good as the corner cases you can think of.
C***-2 concern Not being able to apply to everything
C***-2 concern Rely on test case rather than spec
C***-2 concern Paradigm shift---so may take a while to see gains
C***-2 concern * The focus is test not proper design * You must now keep 2 sets of code, test and devel. 2x the possibility of errors. * Test may not address branched tests only linear testing. * A lot of code refactoring a lot of time because the design was not considered to begin with
C***-2 concern Induction of Mindset of incremental tested software. And even more so, cultural shift in writing test first within organization
C***-2 concern More time consuming. Adapting to new method . Is all the corner cases covered or anything is missed in this TDD
C***-2 concern 1. Did not see way to do debugging with stepping and variable inspection. 2. Will have to include in PBI estimations (and explain to project managers) the time spent without producing any feature code to demonstrate.
C***-2 concern Are we working at a very low level without a proper preparation such as requirements analysis or high level design?
C***-2 concern - more code to maintain. - note everybody sees benefits of more code up front.
C***-2 concern * Seems like a time consuming activity as we introduce some logic (takes time to think through) to satisfy a test. Later on , we remove and introduce the logic again to satisfy the next test.
C***-2 concern How do I add Tests to my existing/legacy code?
C***-2 concern 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 concern small steps, not thinking
D**-2 concern The feasibility of interfacing with hardware functions
D**-2 concern There are still corner cases to be covered and additional tests.
D**-2 concern That I will leave something untested (not thinking through all the tests cases, leaving an hole in the test coverage)
D**-2 concern In embedded development, the real problems are in hardware timings and these are much harder to test.
D**-2 concern Nothing really. Just maybe, how usable and portable different frameworks would be. probbaly difficult to handle existing/legacy code
D****-2 concern feels slow It FEELS it takes longer to accomplish simple tasks, causing some anxiety in terms of perceived progress.
D****-2 concern Grrr Not being able to think ahead and write the code to make design decisions that I know I am going to make. Having to write the bare minimum code to make the test pass often times frustrates me.
D****-2 concern Laborious TDD has more deliverables since the functional code and the test code are required. This could appear as a hurdle to some.
D****-2 concern legacy It seems very straight forward for new development but very hard to wedge into legacy code.
D****-2 concern self-limiting It's really hard to limit myself to the smallest possible change.
D****-2 concern Test Mistakes Writing bad tests which give you a false sense of security.
D****-2 concern time Not implementing it in the correct way. I.E. with a 'develop, test, TDD' mindset will simply produce more work.
D****-2 concern time consuming It feels time consuming without building momentum.
E*-1 concern Does not fit how I code. Initial time to adapt it into normal work, and will others use and maintain the unit tests.
E*-1 concern Does not fit how I code. I did not like hardcoding values to get tests to pass. That goes against long-engrained practices from years of coding and left me feeling like I might forget to go back and fix it.
E*-1 concern Hard to think of the tests Its a new way of thinking.
E*-1 concern Hard to think of the tests Up front development time needs to be incorporated into project estimations. Understanding that features may take a little longer but less development time solving bugs in the future.
E*-1 concern Other. overhead of test
E*-1 concern Other. I have concerns that hardcoding functions to pass test can lead to missing requirements which will then not be caught by the test suite.
E*-1 concern Other. inaccurate test results due to hardcoded values
E*-1 concern Too much test code. How quick can this approach be adopted by a team.
E*-1 concern Too much time. I would be concerned that it may take more time to develop code using this approach. Although I think with practice things would move faster.
E*-1 concern Too much time. More time up front for coding to save time later can conflict with deadlines when management doesn't understand this method.
E*-1 concern Too much time. overall time spent debugging test code
E*-1 concern Where are the requirements? need to write full test case
E**-1 concern at least in this example it push me to write non sense code which was obviously wrong form teh beginning
E**-1 concern When creating a new function I have things in mind about how to write it well that I tend to forget when I get back to it later.
E**-1 concern That all the test passed but the code is still not working correctly in some specifics case
E**-1 concern The time that it takes (for a beginner)
E**-1 concern seems to be really usefull only for pure algorithms, not very suitable to HW interactions or GUI or statemachine
E**-1 concern It's easy to forget a test or functionality. In this example we forgot to calloc the buffer but all the tests were passing because the buffer had a great enough value for the tests.
E**-1 concern Forget to test some cases (test coverage)
E**-1 concern I will forget to test something and that part of design will remain unimplemented/stubbed.
E**-1 concern Sometimes when I'm coding, I think directly to the next steps and I have to write it down to not forget it
E**-1 concern Initially passing test is not tested and therefore might be wrong and passing all the time/hide some bugs.
E**-1 concern couldn't write straight the "right" code
E**-1 concern It would be hard to follow the tdd rules for all developing process, especially at the begging of project....
E**-1 concern It's more time consuming from first point of view. May be its benefit appears in testing stage of the development process when there are not so many bugs in the code?
E**-1 concern Maintenance of the test code
E**-1 concern It is the programmers responsibility to not rush ahead and do incremental steps only.
E**-1 concern While TDD works almost fine on some known thing as CircularBuffer, it might be difficult to use it that way on some not-yet-designed custom module.
E**-1 concern I'm concerned that TDD works well when writing a module that has no dependency to other modules, but might be a nightmare otherwise.
F**-1 concern architecture - How can we know that the test cases are enough? - If we only write the code to pass all the test cases, we may not think much about the architecture to expand more in the future.
F**-1 concern Code coverage Can we achieve 100% code coverage by using TDD?
F**-1 concern confusing I wonder if writing a small piece of code then test it or writing a module based on the design is better. I feel that it really hard to design a module by the way we did in exercise 1.
F**-1 concern confusion My concern about TDD is how to write full unit test case for my project which is maybe so complex.
F**-1 concern Cover all cases Time spend to test Does the test cover all cases?
F**-1 concern cover all use-cases When do we know our test cases can cover all the use-cases?
F**-1 concern Deadline In real project, maybe project cannot follow full workflow of TDD. It will take too much time to done Unit test, integrated test, system test.
F**-1 concern Design test case I concern about: 1. "hardware dependence": errors can come anytime from hardware, I dont know how TDD can cover it. 2. We must have Testcase design technique before appling TDD?
F**-1 concern Hard Hard, take more time to dev
F**-1 concern normal It takes me a lot time to develop task with TDD. But I will try it.
F**-1 concern Practice Takes time to get familiar with.
F**-1 concern refactor time In a large system, does it take much effort to refactor code for every new test case?
F**-1 concern Stranger I make me stranger things. Because It's news for me. Do we need it when my system's small?
F**-1 concern Strong How to test all function with simple, cover all condition
F**-1 concern taking time It takes more time to develop features
F**-1 concern test the tests - Do we ALWAYS need to make the test fail before making it pass? - How we make sure the tests cover all the corner cases?
F**-1 concern time Is it save time to develop and maintain system ?
F**-1 concern Usability - Dependency between modules in system. - For embedded, how to test things that interact with peripherals or use peripheral inputs - Different in target and host compiler
H*-1 concern Very granular approach to creating tests and associated functionally seems like it could be inefficient inefficient in some cases. Sometimes it might be better to think more holistically about the problem.
H*-1 concern Wondering how it will work in large complex designs. Afraid of writing a lot of tests that don't matter, and missing ones that do matter.
H*-1 concern I'm concerned that applying TDD to our existing code base will be untenable.
H*-1 concern We have such a "we need this NOW" mentality that I think it may be hard to justify the time spent on testing (even though we all know that it will save time in the end).
H*-1 concern There is a lot more stuff, both test-code and implementation code to keep track of. It gets messier as you add more functionality to the code since you would need to revisit both test and development.
H*-1 concern The impending doom (read: tons of tedious work) I feel creeping towards me as I realize I have to somehow mock-up every external piece of code and hardware my code interfaces with
H*-1 concern Developing for hardware using TDD doesn't seem as simple
H*-1 concern I question knowingly writing code that would not work in production, just because you haven't gotten around to writing a test to catch the fault yet.
H*-1 concern Not sure how this translates to a real time embedded system that is several orders of magnitude more complex.
H*-1 concern My concerns with TDD is that I am already being pushed to give partners code faster, this will increase the quality of my work but will slow down my delivery time. How do I explain that to my partners.
H*-1 concern The steps we were taking seemed wastefully small. Especially writing code that I know is wrong when the "right" code would be very simple.
H*-1 concern Since we were only writing code to pass the incoming test case, it was difficult to "design ahead". If found myself re-writing functions more than I would have with my typical development process.
H*-1 concern I felt like I was trying to come up with creative ways to write the code incorrectly, which seemed wasteful.
H*-1 concern management acceptance of up front cost
H*-1 concern I need time to get used to TDD to get all the values from it. I am not used to hardcode all the value.
H*-1 concern I didn't like being told that I had added unnecessary code, or added it too soon. I would have trouble writing code in this manner.
H*-1 concern If the requirements are not clear up-front, one can easily go in the wrong direction.
H*-1 concern Tests may be created that do not have a clear reason to exist. In the future folks who do not remember or do not know the reason for the test will simply turn it off when the test reports a failure. We don't document our code; I don't foresee us documenting out tests.
H***-1 concern Seems like the development process is slower when using TDD
H***-1 concern I always think few steps ahead of what needed to be done
H***-1 concern Will upper management support the additional time before they see the pretty lights blink? Yes I know the overall development time will be less and the quality higher.
H***-1 concern Step size. How to define what is too simple...
H***-1 concern While the take a simple approach is good and can be thorough, I find that our team sometimes struggles getting documentation of all the requirements. I started using empty test cases as documentation but found this confused some team members. More importantly getting people to really understand that they are doing the minimum solution for a subset of the requirements needed for a 'solution' is often a challenge.
H***-1 concern The time it may take to develop complete solutions
H***-1 concern The biggest concern is over-testing. Knowing when to stop is important. How many test cases for an individual function should be tested? Do I test this library provided by the language? If so, how completely? When is there something I can't test because what I want to test is just not testable?
H***-1 concern The time required to have something to show for progress. Most schedules and expectations are from the waterfall approach to development. Will take some time for everyone to adjust.
H***-1 concern It takes way too much time then you get in return
H***-1 concern None yet
H***-1 concern Time.
H***-1 concern How to verify my code? How to make closer to bug-free?
H***-1 concern Time it takes to write the test cases
J***-1 concern All the above. How do we get started? What setup is involved in getting this to the starting point provided?
J***-1 concern All the above. This seems to be okay for new start.. how do you apply this to existing legacy code.
J***-1 concern Does not fit how I code. Intentionally not implementing the full (or even any) functionality is uncomfortable and seems prone to future errors
J***-1 concern Does not fit how I code. Just a new way to approach coding. If I adopt this new way of writing, it'll be a push against the current standard.
J***-1 concern Does not fit how I code. Intentionally not implementing the full (or even any) functionality feels uncomfortable
J***-1 concern Does not fit how I code. Purposely writing code that is wrong. Not just stubbed, but wrong.
J***-1 concern Does not fit how I code. It was always considered bad practice to rely on a compiler to code well. This seems to be the basis of this methodology.
J***-1 concern Does not fit how I code. It can be challenging not to get ahead of yourself when coding.
J***-1 concern Hard to think of the tests In the drive to get tests passing, some shortcuts are taken. I'm concerned if the tests do not get revisited to flesh out hard-coded behavior, giving the illusion that all tests are good.
J***-1 concern Hard to think of the tests Since TDD is new to me it is a bit challenging to do it on the spot.
J***-1 concern Other. How do you avoid overly brittle tests that are far too sensitive to internal changes?
J***-1 concern Other. Getting used to the steps/mentality of TDD can be challenging because of the "fake it 'til you make it" approach to implementation. It feels strange to make something that is wrong on purpose.
J***-1 concern There is no design. Using partial implementations with otherwise incorrect behavior to satisfy early tests opens up a risk of forgetting about something if you forget to write a test for the affected condition(s).
J***-1 concern Too much time. The added time it may take initially (even if it saves you time on the back end)
J***-1 concern Too much time. It would be difficult to implement in a complex code base that has already been developed
J***-1 concern Too much time. How to handle changing requirements? After TDD, I have X lines of source code plus Y lines of test code. When a client changes a requirement, now I have to rework X + Y lines of code.
J***-1 concern Too much time. The process seems to require re-writing code, which could be time consuming
J***-1 concern Too much time. It new to me and takes longer
J***-1 concern Too much time. test concern
J***-1 concern Too much time. test from lounge on concerns page
J***-1 concern Too much time. hey, 2:57 fri
L*-4 concern apply It's good. I'm not sure that I can apply it to my project.
L*-4 concern asynchronous system I'm making the product rely on the asynchronous system, how can I write the unit test for that system?
L*-4 concern case missing Takes too much time and can miss cases
L*-4 concern Coverage It look like it's important to make high test case coverage. If we make test case with low coverage, we can't verify a lot of bugs.
L*-4 concern coverage If a program has long and complex codes then how can test codes cover all cases?
L*-4 concern deadline to deliver My concerns about TDD are difficulty, no time and maintenance. Test codes would be difficult to be made. I will have no enough time to make the tests. I should maintain the test codes after I made.
L*-4 concern dependency This kind of unit test useful for only pure function testing. However in the embedded system, there are some dependency with HW or external input data. I think it may hard job to replace it as Fake.
L*-4 concern dependency When module has a dependency of external environments such as network and server, how can it be include in test codes.
L*-4 concern Hard to continue It's hard to get used to it. Hard to keep continuing when i have short time to do some prototyping.
L*-4 concern legacy Can I apply TDD for the legacy codes when I change part of them?
L*-4 concern Limited-Time Spending some time to make TESTs.
L*-4 concern not enough time I don't have enough time to develop full test case on my real work.
L*-4 concern pass Making test code to only pass.
L*-4 concern practice Can I make every test codes when I write codes in the real work?
L*-4 concern range how much test range is similarity with real testing
L*-4 concern test case Sometimes I faced the limit of my imagination, how can I specify test cases which is fully testable my module?
L*-4 concern test for corner case I concerns about how to make test code for corner case.
L*-4 concern testcase How do you systematically write test cases?
L*-4 concern time hard to categorize the test case time consuming
L*-4 concern TIME I think TDD will take long time to develope software. How about big project? Can TDD be applied without project size?
L*-4 concern too much code Test code is too much. For example, if source code is 5 lines, test code will be 20~25 lines.
L*-4 concern unnecessary I had to too many code to test my codes, and some seem to be unnecessary. And When I modify INTERFACE, I also have to modify my main code as well as test cases
M***-1 concern easy to skip tests you have to think about everything that can go wrong. Its easy to skip tests
M***-1 concern incomplete The many steps make it feel as if not all things are tested, especially the first few (very simple) tests...
M***-1 concern more time Longer development time before first working proto release version.
M***-1 concern Overthinking I notice my mind tries to go 3 steps ahead instead of sticking to the step-program. Hard to shutdown/slowdown
M***-1 concern Overview After a while I am doubting whether my original tests still provide the "correct" coverage /mindgames?
M***-1 concern Overview The sheer endless amount of tests you write may clutter the overview of what is tested, and what not (yet).
M***-1 concern redundant Total running time of test suite might become to large because of a lot of redundant tests.
M***-1 concern situations I am not sure if we tested everything there is to test up to now
M***-1 concern Tedious Takes more time, especially on smaller task where you already might know all the pitfalls or how your implementation should behave. It also is a bit hard to stick to TDD in that case
M***-1 concern ToAddAllTheTests When writing the tests, not to miss come test condition.
M***-1 concern use in embedded needs initial effort
M*****-8 concern Time to implemented the test in this way
M*****-8 concern Getting the right balance of how far to look ahead in deciding what to implement. Could make a lot of the initial tests work by just using simple flags, however, that wouldn't be adding anything to the real functionality that you know is required as you get to more complex requirements.
M*****-8 concern How it can work in a complex project
M*****-8 concern We can't deliver components "Functions" incrementally. We have to implement all test cases before starting integration testing.
M*****-8 concern the development environment is not usable in my work because the project is very complex
M*****-8 concern Writing code that doesn't meet the end requirements seems wrong.
M*****-8 concern A little cumbersome
M*****-8 concern How to maintain the 'state' of the code in your head if you are subject to frequent distractions. Sometimes you know the code is not 'final', but is good-enough for the current tests to pass. How do you remember to go back and fix the stuff that is not 'final'?
M*****-8 concern End up rewriting things as initial focus is on getting test to pass
M*****-8 concern If the test coverage is low or poorly thought about, the quality of program will be lower because the programmer do not put enough effort to implement.
M*****-8 concern You could write passing tests (and hence design code) that doesn't actually meet a top-level requirement.
M*****-8 concern What happens when tests takes a long time to run. I think the development time may increase because when developing a feature you want to focus on the design and having to stop to do the test/coding iteration may slow you down.
M*****-8 concern development slow due to continual refactoring as write new tests without considering wider scope initially
M*****-8 concern time consuming
M*****-8 concern - the time to market go in contrast with the time needed to build up our code through a test driven approach - how to test complex systems
M*****-8 concern - slow process
N**-2 concern The process getting in the way of progress (while learning it)
N**-2 concern It seems hard to be disciplined enough and to write the right test
N**-2 concern TDD makes a lot of sense, but I'm concerned of how efficient it becomes when requirements are unclear.
N**-2 concern Should not conflict with defensive programming where testing is hard.
N**-2 concern It is easy to get the test wrong without realizing it
N**-2 concern Confusing, I didn't always see where we should stop "faking" or what should be hardcoded.
N**-2 concern Its hard to think like a developer and a tester at the same time.
N**-2 concern A lot of extra code to maintain.
N**-2 concern none
N**-2 concern Afraid I'll forget to finish the real implementation of a function
N**-2 concern You can write the wrong test
N***-1 concern Hard to think of the tests How to decide on which tests are appropriate.
N***-1 concern Hard to think of the tests Avoiding redundant cases and balancing between bloating testcases and finding corner cases.
N***-1 concern Other. Again about the legacy code base: my understanding is that TDD is an approach for *developing* software and that TDD is not about writing lots of tests for existing legacy code
N***-1 concern Other. It could be useful for new code (with all the requirements/specs defined). I'm a bit concern of how to implement this with our current software (legacy, convoluted, too many dependencies/includes)
N***-1 concern Other. Gives me anxiety when you can see the future problems at the earlier steps and you can't code ahead
N***-1 concern Other. It remains to be seen how this can be applied to our legacy code base
N***-1 concern Other. Applying this to neato's codebase because of tight coupling / dependencies
N***-1 concern Too much time. Seems like a slow process.
N***-1 concern Too much time. Iterative and might increase the development time exponentially. The design is happening during code. The lack of a high level design can seriously mess with large code-bases.
N***-1 concern Too much time. I did not like having to wait ~5 seconds every time I ran the tests
N***-1 concern Too much time. Might be time-consuming initially.
N***-1 concern Where are the requirements? A test being inaccurate and not noticing (leaving something hardcoded)
N***-1 concern The environment looks complicated to setup/replicate.
N***-1 concern Sub-optimal code as a result of not thinking ahead.
N***-1 concern I am spending a lot of time "growing" the software by faking. I think if I spent ten to fifteen minutes planning ahead I could go through the same cycle of writings tests, then code, and refactoring, but be more focused on my target.
N***-1 concern Knowing what tests to write
N***-1 concern There is a lot of time spent defining tests
N***-1 concern It seems difficult to go back and make changes if I need to.
N***-1 concern It seems that creating the smaller steps would increase the overall development time.
N***-1 concern I'm not sure that the person writing the code should be the one creating the test.
N***-1 concern This demo environment is nice but how do we integrate a unit test framework into our existing environments.
N***-1 concern At no point in the process was I encouraged to think at a high level about the design of the module. Maybe that will turn out to be a good thing, but it seems like it could also result in poor performance (if the code works) and/or wasted time if lots of refactoring is required. Also, it feels strange that I'm intentionally inserting bugs into the code (faking functionality), trusting that at some point it will be caught by some test and I'll be forced to fix it. What if I fail to write good tests and some intentional bugs are left in? Wouldn't it be better to try to write it correctly the first time to minimize that possibility?
N***-1 concern Potential time it could take to setup tests when using/modifying existing code.
N***-1 concern Hard (but getting there) to change mindset to test first.
N***-1 concern What happens once the FW starts to touch the HW
N***-1 concern What needs to take place prior to TDD, for the demo the API was defined and some requirements listed
N**-2 concern Does not fit how I code. My lack of understanding of C
N**-2 concern Hard to think of the tests Its a tighter test/write loop than I'm used to.
N**-2 concern Other. How does this scale up to higher order tests - perhaps functional or whole system?
N**-2 concern Other. It requires discipline which I lack.
N**-2 concern There is no design. Without design or architecture up front, how do we keep the design from going totally off the rails?
N**-2 concern Too much time. May take very long to complete the overall task assigned.
N**-2 concern Where are the requirements? Getting to know the framework
N******-2 concern How can it be implemented in our alread existing (a lot of) code.
N******-2 concern Too many incremental steps may waste time
N******-2 concern to stuck in fixing testing code when changers are made in functions to test
N******-2 concern I am concerned if I can imagine and make correct tests
N******-2 concern In early stages those hard defines just to get the test to pass or fail which, in a scenario that does not cover all the test might lead to failure.
N******-2 concern How to implement TDD in more complex system.
N******-2 concern Some time spent just to get the compiler happy with initial definitions and declarations.
N******-2 concern > strong dependency with requirements, can end-up in much more effort (implementation + test code) > not sure about size of test fixture, level of details,...
O****-1 concern I'm concerned that I might not be able to apply TDD to my daily work.
O****-1 concern one small step at a time
O****-1 concern i am not able to avoid to add untested code. temptation too high
O****-1 concern - that it takes a long time to write code and to meet Project demands - not to know what the macros are doing in the background
O****-1 concern If something is not tested you might end up with false positives
O****-1 concern Maintenance ot the tests. Especially if code goes thru different hands.
O****-1 concern Making tests not working properly gives a wrong feeling of correctness of the code
O****-1 concern Getting the right tests written is not trivial, and that might extremely change the quality of your code
O****-1 concern the complexity of the work in a real project
O****-1 concern Sometime you loose the overhall SW architecture
O****-1 concern sometimes you are just trying to pass the tests. Like VW did. ^^
O****-1 concern Writing a simple module might take a long time
O****-1 concern first need to write the tests of course
O****-1 concern How to apply at application level? Is worth for all cases/prjs?
O****-1 concern The example "Circular buffer" is very small on complexity. I can imagine that TDD with bigger implementation is more difficult. Maybe you have to Strip into smaller pieces.
P***-1 concern It may take twice the time fore writing the same code. Developer may not be able to think of the complete set of tests while developing in 'happy path'.
P***-1 concern how to fit it in real scenarios, where there are a lot of thirdparty components,
P***-1 concern If the interface (or test cases) are not carefully developed, then the code can be pushed in the wrong direction
P***-1 concern
P***-1 concern How to apply TDD for existing source code?
P***-1 concern If build or programming time is too long, it takes long time to write the code.
P***-1 concern - Practicing TDD requires maturity. You need to learn how to be humble. - TDD is slower to get results at the beginning but makes up for the time spent in the end. Project Leads may not be patient when it comes to meeting a deadline.
P***-1 concern No Concerns Still now. Curious on what we are going to do when we have a thread.
P***-1 concern Coming to know about all the test scenarios/inputs may be not possible to 100%
P***-1 concern The overhead may not be worth the time spent. Some of the test cases may never be exercised by the application.
P***-1 concern time consuming when considered with project timelines.
P***-1 concern TDD will increase my overall development time
P***-1 concern There is overhead to so many iterations.
P***-1 concern I don't really know the code coverage in test. I may need to run TDD and regular unit tests to make sure the code works as expected.
P***-1 concern How do we achieve the maximum coverage?
P***-1 concern Developer distraction.
P***-1 concern Future concern - How am I going to deploy this TDD in my project development.
P***-1 concern more refactoring and more time
P***-1 concern Could be difficult to implement in already existed piece of code or framework. and also it may be a bit lengthy.
P***-1 concern If the design is still in prototyping phase, the design might be changed dynamically. People might want to see if the happy path works, then polish the design. In this case, TDD might be slower than the traditional approach.
P***-1 concern How to be sure that the correct/enough test cases are considered while doing TDD, is there a formula for evaluating number of lines vs test cases
P***-1 concern Time
P***-1 concern The process results in a large amount of code churn
P***-2 concern maybe ok for lesser complex application but for complex application, TDD seems not to be realistic
P***-2 concern TDD will increase the development time exponentially
P***-2 concern Takes almost double the time as development Need to write effective test cases to cover the code
P***-2 concern If the developer himself creates the test cases then that would lead to weak test cases. Because he is currently trying to develop the code. It is an art to learn about Use Cases and Corner cases and then create appropriate test cases.
P***-2 concern I feel code is not well design from the beginning.
P***-2 concern No concerns as such now.
P***-2 concern How to apply it in a practical way
P***-2 concern Expectation to make deliberate compilation and link errors
P***-2 concern I think development time might get increased.
P***-2 concern Unintuitive, difficult to follow the basic principles. Create failing test, just make the changes needed to pass.
P***-2 concern Adding this activity in to an "In Progress" project"
P***-2 concern Whether the project timelines permits implementation of this idea. How to we address creation of stubs without much overhead? How this will come handy when we implement platform dependent functionalities?
P***-2 concern creating an extensive test case suite would require knowledge of all the macros that the framework would provide
P***-2 concern
P***-2 concern TDD may take longer to code than normal
P***-2 concern not help much with legacy code that can't be changed much
P***-2 concern What if the entire code stream is very big? It will take huge efforts to write all the unit test cases.
P***-3 concern Increases coding time
P***-3 concern 1.Can we test asynchronous returns using TDD. 2.Is there any underlying platform dependencies for porting TDD onto different target.
P***-3 concern Hard to implement in already developed code
P***-3 concern Teach us how to test our code
P***-3 concern Development time
P***-3 concern 1. Number of line of test code. 2. Initial effort is more.
P***-3 concern We write the code based on test cases. As tests cases progress we keep modifying the code. This seems we are writing code for test cases.
P***-3 concern Is TDD good for every field in development?
P***-3 concern Lots of concerns. 1. What about design? Pre-conditions, post-conditions, invariants? 2. Felt like I was careening from test to test - not at all comfortable about correctness 3. I suspect that tests alone are not sufficient to fully specify behavior. In the absence of a design, how can I be comfortable that the work is ever completed? 4. Several tests passed on the first go (perhaps I implemented "too much" in a previous step) - no way to determine if my tests were wrong, or my implementation good (e.g. Test could be passing vacuously or erroneously). Test passed, move on! 5. Copious use of copy/paste! Arg! I always tell my team that Copy/Paste is NOT a design pattern. Apparently it is in TDD.
P***-3 concern It takes some time effort for writing test cases.
P***-3 concern Takes a lot of time to complete correctly
P***-3 concern Increases the development time
P***-3 concern I would be concerned that someone would mistake this as an alternative way to approach problem solving versus understanding how to solve a problem in the first place.
P***-3 concern Writing more code to test code
P***-1 concern My My immediate concern is how easy this is to implement in different development environments.
P***-1 concern Doing implementations the "wrong" way (i.e. making things work with code that don't move towards the correct implementation).
P***-1 concern slower initial development speed
P***-1 concern how does it work when working with 3rd party libraries
P***-1 concern instead of thinking about the problem we use DIE code, i.e. Debugged Into Existence
P***-1 concern creating enough corner case tests etc
P***-1 concern What happens if you disturb a programmer (comic): http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/
P***-1 concern Running on embedded systems
P***-1 concern Sometimes is hard to know when to fake it or make it It is hard to procrastinate, we want to make the real implementation from the start Changing API can make a lot of tests fail, and if we have been using copy paste instead of utility functions early it is a lot of search and replace
P***-1 concern Circular Buffer is just a training excersize. Should one go for the smaller incremental steps while test driving or can one take larger steps as long as the tests written ahead cover the functionality implemented?
P***-1 concern Having to refactor a lot if I change my mind about how functions should behave.
P***-1 concern Maintaining hundreds of existing tests when I, two years later, need to make a significant (e.g. architectural) change to a working system. (Although, I would rather do that than have NO tests fro this system)
P***-1 concern If you start out writing bad code only to get the tests to pass it can be difficult to solve the problem later when you need to get all the tests to pass.
P***-1 concern It takes some discipline.
P***-1 concern When developing on embedded HW the test you created to begin with may not be what you actually need to get the HW to work. Eg. turn on power, init SPI bus, read "WHO AM I", read data, close bus, turn off power etc. Hence,the process may need many iterations.
P***-1 concern testing functions that require communication between 2 MCUs
P***-1 concern ensuring there are no bugs in the tests
R**-1 concern Does not fit how I code. completely breaks my way of thinking about a problem. forces me to do things wrong, just to fix them afterwards --> ineffective. have i mentioned that i like "the borg" from star trek?!
R**-1 concern Does not fit how I code. It requires to change the perspective very often. I would prefer to concentrate on a solution for a longer period. I don't like temporary solutions just to have a response to test case.
R**-1 concern Hard to think of the tests Might get confused what test i did already and what needs still to be done.
R**-1 concern Hard to think of the tests Maybe I forget something I made in order to get my test to run but should be implemented with functionality.
R**-1 concern Hard to think of the tests It is hard not to jump into implementation and test one behaviour at a time.
R**-1 concern Hard to think of the tests At the end, I think I was writing "too much" code at once, without being able to cut it into multiple parts (the wrapping around part)
R**-1 concern None Making tests
R**-1 concern Other. Incrementally discovering the API might not lead to the best possible API. If I discover my API is bad after writing 60 tests, I have to change a lot!
R**-1 concern There is no design. TDD may leads you to not think about good design or implementation, because you are only trying to get the tests running ;)
R**-1 concern There is no design. Difficult to accept "forgetting" about the design you have in mind and concentrate on smaller steps. My head had the whole concept already in mind, and accepting to write down "temp" code was hard
R**-1 concern Too much test code. that's a lot of code (yet simple) for a "basic" implementation of a problem. I can't imagine how long it becomes for complex systems :/
R**-1 concern Too much time. I think writing test code for hardware / testing physics can be very difficult and time consuming. For example testing what the actual output on an SPI bus is or whether a GPIO state changed.
R**-1 concern Too much time. It's longer than usual, but I think it worth it !
R**-1 concern Where are the requirements? Test´s don´t really cover the full functionality. Production code can be faked easily
R**-2 concern Does not fit how I code. Hard to carry out if something has to be adapted in legacy code.
R**-2 concern Does not fit how I code. Usually i do not write code till i have a plan how everything should work. First writing wrong/empty code to get failing tests feels like additional work. (But i also see the good side of it.)
R**-2 concern Does not fit how I code. Not yet sure when faking it is harder than writing the real thing
R**-2 concern Does not fit how I code. Theoretical approach that one has to get used to first
R**-2 concern Hard to think of the tests it takes a lot of time; its "new thinking"
R**-2 concern Other. If the project grows, the compile time might get too long. What about third party dependencies? How to deal with them?
R**-2 concern Other. When a problem becomes more complex I will not be able to write all tests. Without TDD I was not able to write the code. In any case the problem will not be solved.
R**-2 concern Other. No worries at the moment
R**-2 concern There is no design. Both implementation and test are undocumented.
R**-2 concern Too much time. I'm worried if I have time to write that much test in real projects. Is it necessary to test every little detail?
R**-2 concern Too much time. something
R**-2 concern Too much time. Based on the timeline it may take too much time upfront.
R**-2 concern Where are the requirements? We are moving forward from ant perspective of view. Implement before thinking may provide into blown up code.
R**-2 concern Where are the requirements? We have not yet tested non-functional requirements like speed and memory usage.
R**-3 concern Does not fit how I code. Breaks the development cycle. If I am in the middle of implementing something, I need to write tests in a separate project, or prepare tests. I get back to the original problem maybe one hour later.
R**-3 concern Does not fit how I code. Hard to get rid of old habits.
R**-3 concern Hard to think of the tests The tests should be written after writing the functional code. Sometimes it's really hard to design a good testing schedule for the functional code
R**-3 concern Hard to think of the tests It is difficult to make a step-by-step implementation (code/test).
R**-3 concern None Writing tests for GUI might be more challenging.
R**-3 concern Other. Nothing to complain
R**-3 concern Other. Not always easy to split tasks, I Often make many tasks in the same time. Need practice Also how and when design our code in these steps ?
R**-3 concern Too much test code. You get caught up into testing too many things which are maybe not necessary
R**-3 concern Too much time. Implementing the tests might be more work than the implementation it self.
R**-3 concern Too much time. Slows down the development of "easy" tasks
R**-3 concern Where are the requirements? The implementation of the circular buffer has only less complexity. I wonder if TDD will also been working on complex tasks as well.
S***-1 concern Does not fit how I code. Requires discipline and a change in thought process and activities
S***-1 concern Hard to think of the tests Tests could become complicated and it may be difficult to tell if there is an error in the test setup vs an error in the implementation
S***-1 concern Hard to think of the tests Here the tests were already written for me. But, having done this before, I know it can be difficult to think of tests, and to know that the test you come up with is a small enough chunk.
S***-1 concern Hard to think of the tests If you forget one use case and it comes up later, you have to find all the instances where it comes up. Just feels like chasing my tail.
S***-1 concern Hard to think of the tests Everything depends on robust tests, it's difficult to determine what should be tested first and how the test cases should be designed. The order in which you add tests could change the code structure.
S***-1 concern Hard to think of the tests This is great for code that doesn't rely on outside data/sensors/environment/peripherals. I guess this is where DBC checks, etc. fit in real-time code.
S***-1 concern Other. I still don't understand the concept. If I can understand the CircularBuffer excercise at least up to the GET ad PUT methods then I will probably understand TDD.
S***-1 concern Other. It's difficult to hold back wiring the whole implementation while doing TDD.
S***-1 concern There is no design. for the demo, not scoping worst case of circular buffer with memory constrained devices, dynamically allocating memory concerns me.
S***-1 concern Too much test code. It seems like you could end up spending as much time writing the test code as you are writing the actual code.
S***-1 concern Too much time. This approach took a lot time and in the beggining I was kind of faking passing the test eventhough I knew exactly how to fix it.
S***-1 concern Too much time. Is it really going to be faster overall?
S***-1 concern Too much time. When implementing more tests/code, I had to go back and update previous tests that had inadequate coverage. This made me less confidence in earlier tests, since I would need to rebreak/retest them.
S***-1 concern Too much time. This is a shift in the way we write code. Seems like you are investing in the future by doing this and therefore it requires a bit more upfront time.
S****-1 concern Are my tests correct?
S****-1 concern Nothing really. The time it takes 'extra' will save me debugging later I believe.
S****-1 concern Takes a lot of time, writing header separately, testing, writing implementation, testing, change test etc..
S****-1 concern To Don't have the patience to keep iterating through the steps
S****-1 concern As code base grows, the iteration time (compilation, running tests, etc) will increase.
S****-1 concern Added development time (but less code rework)
S****-1 concern To forget creating a test and then also forget creating the needed production code
S****-1 concern The amount of time needed to build and test each time concerns me.
S****-1 concern Build response times need to be within second(s)
S****-1 concern How can this be implement into an Embedded environment where external stimulus is required
S****-1 concern What if the system is under-specified?
S****-1 concern - To be able to do this you need fast compilation
S****-1 concern It takes a lot of discipline to make only one (very) small step at a time
S****-1 concern Different way of thinking, hard for "stubborn" developers?
S****-1 concern bit slow sometimes wrong direction
T***-1 concern 851 concern 851, revised, again, one more time. and again
T*-1 concern All the above. nothing yet.
T*-1 concern All the above. nothing yet.
T*-1 concern Does not fit how I code. A bit irritating in the beginning
T*-1 concern Hard to think of the tests if test code is not fully covers the problem the code is not fully functional!
T*-1 concern None Do not have any concern about TDD.
T*-1 concern None additional effort to write first test and than function, guess will need more time if we not just remove comments
T*-1 concern None A bit irritating in the beginning
T*-1 concern Other. Good for new software, but not so good for changing existing software (not yet covered by tests)
T*-1 concern Other. - sometime misunderstanding test result (example what yellow sign really mean)
T*-1 concern Other. Good for new software but I'm wondering how it will work for code already existing and without tests yet.
T*-1 concern Other. Testing code which calls other code might be expensive (time, environment)
T*-1 concern Other. who do I reach the end of the test code? when I is finished? who decides this?
T*-1 concern Too much test code. Sometimes slow in synchronizing code changes to other team member.
T*-1 concern Too much time. TTD is very time consuming, but it will help to avoid problems at the beginning
T*-1 concern Too much time. seems to need more time for coding
T*-1 concern Where are the requirements? New kind of thinking. Test harness everytime availbale?
T**-1 concern Awkward I already had a vision in my head, but implementing it in this manner seemed to slow the process and felt awkward.
T**-1 concern change defining the interface is difficult changing the test cases when the interface changes
T**-1 concern dependencies How to make it work with complex dependencies.
T**-1 concern design May lead me towards a design that I'll regret later because I didn't do as much upfront design work.
T**-1 concern experience Require experience to how many tests or how much to test on one function/class. Things you can't think of testing may remain as a hidden bug which very difficult to figure out.
T**-1 concern legacy How to make it work with legacy code.
T**-1 concern slow Feels slow when I think I already know the implementation required.
T**-1 concern syntax New keywords/test syntax to learn. Need cheatsheet/quick reference to help make development of tests efficient
T**-1 concern time Painful. A lot slower than normal development. A price for the benefits but still something I don't like.
T**-1 concern too early Just started learning it so I feel too early to raise any concern
T**-1 concern which-is-wrong Discerning if (when) the test is wrong instead of the code under test
T**-1 concern who knows TDD seems to be geared more to a system which has its requirements defined before development begins. Significant changes to requirements could be costly (time)
U**-1 concern Does not fit how I code. Slightly prescriptive test regime in terms of how it would cope with multi-threaded systems.
U**-1 concern Hard to think of the tests Tests could be wrong
U**-1 concern Hard to think of the tests It is sometimes difficult to imagine the simplest solution.
U**-1 concern Hard to think of the tests It may take too much time for test-modifying-more tests-more modifying circle. I prefer to dump some log to see how things works.
U**-1 concern Hard to think of the tests It may take too much time for test-modifying-more tests-more modifying circle. I prefer to dump some log to see how things works.
U**-1 concern Hard to think of the tests It may take too much time for test-modifying-more tests-more modifying circle. I prefer getting some debug log to see how things works.
U**-1 concern Hard to think of the tests I fear losing focus on final desired module behavior. While designing the code, you are also busy with designing the tests. And if you don't test in the proper way, a bug might not be hit and found
U**-1 concern None Prograstination and lazy steps to get test pass has to be done in a smart way.
U**-1 concern None We will still able to add bugs that the tests didn't catch, so need to think more about what to tests needed. That doesn't mean thinking the tests was hard, just don't assume have caught all bugs.
U**-1 concern None Will it be as time efficient with bigger projects or when integrating older code?
U**-1 concern None How it will be applicated on our existing code that is more complex and already written
U**-1 concern Other. I am not sure if there are much benefits in enviroments with extremely good design stage or the opposite one, poor design phase, kind of I am not sure what I should do.
U**-1 concern There is no design. Code churn (in my experience churn introduces bugs) High proportion of time writing tests Don't have a good handle on the overall design Writing code like an automaton (creativity--)
U**-1 concern Too much test code. maybe the applicability in an existing project with interaction with other module. It takes time to have it all done
U**-1 concern Too much test code. There is maybe quite a bit of test code that could be hard to maintain
U**-1 concern Too much test code. Maintainability of the test cases could be expensive and it makes your design rigid to the change. It takes more time and effort to modify the test cases if you decide to do some major change in API.
U**-1 concern Too much time. Will it be as time efficient with bigger projects or when integrating older code?
U**-1 concern Where are the requirements? the number of steps to writing the test feels tedious at times
V****-1 concern Solving the simplest problem and ignoring the bigger picture is going to compound your pain.
V****-1 concern At first blush, it appears to take longer. I know that will be disproved.
V****-1 concern Still too easy to jump ahead
V****-1 concern Take way too much time if the requirement is changed. I may need to go back to revisit many existing test cases
V****-1 concern Occasionally will feel like I am wasting time slowly evolving code (especially when trying to follow the Transformation Priority Premise to a T) when I know what the final implementation should look like
V****-1 concern Will writing tests first slow down the overall coding process.
V****-1 concern Nothing comes to mind so far.
V****-1 concern Too many builds! Our build is not this fast. Also, ignoring the big picture can be costly when it all comes together.
V****-1 concern Writing some obviously incomplete solutions to satisfy the minimum requirement of a test seems to add some unnecessary cycles.
V****-1 concern don't know how to apply TDD to legacy code safely and efficiently
V****-1 concern What am I going to do without comments
V****-1 concern Can be frustrating to switch between writing tests and developing feature
V****-1 concern Seems easier to leave hardcoded values or unimplemented code if you have incomplete tests
V****-1 concern What test do I add next when the implimentation isn't fairly obvious
V****-1 concern Feels like it might take longer
V****-1 concern Don't know which test cases to write
V****-1 concern Don't know what order to write test cases
V****-1 concern Have to potentially go revisit multiple functions to get a test case to pass
V****-2 concern inadequate Implementing code to pass test may not guarantee it does what is supposed to if test coverage is inadequate.
V****-2 concern integration code how to test integrated or system level code
V****-2 concern maintainability If tests are built around an interface will it make changing the code more difficult, as both the interface and the tests will need changing.
V****-2 concern Planning How to make the TDD practices work with legacy code ? Writing the TEST_GROUP function for legacy code can be lot of work. What is a good ratio of test code and code under test
V****-2 concern Scope Developer writing test cases for own code? How much time to devote for writing tests?
V****-2 concern Slow Slows down development time
V****-2 concern time-consuming It is hard to make a conclusion at this point. But it appears to me that this approach may be time consuming. But at the same time I understand that it could be time-consuming in the beginning only...
V****-2 concern useful vs practical How to put the approach into practice under the time constraint.
V**-1 concern Abstracting Concerned about how to scale and use this approach when you work in larger projects that might require a lot of abstraction/generalization/Templatization (e.g. found out when incrementing)
V**-1 concern Awkward It feels a bit awkward and like it takes much more time than the usual way of coding
V**-1 concern build-environment our build time
V**-1 concern context Currently i´m a bit thrown off by looking from two different contexts
V**-1 concern Force to write tests TDD force to write tests for expected results which has to be fixed.
V**-1 concern habits Still need to force yourself not getting into deep coding quickly. Also need to break the habit of trying out possible solutions before constructing tests.
V**-1 concern Implementation here How we can implement this in our own systems with the build times we have for one software component. Too slow feedback
V**-1 concern More work when wrong Sometimes it is really hard to drive the design using test cases. If the abstraction of the interfaces gets wrong, there is a lot to change in the test code as well.
V**-1 concern NoRequirements Where are the requirements
V**-1 concern Not covering all I sometimes felt afraid there were needed test cases we would miss, not covering all expected behaviour.
V**-1 concern nothing nothing.. i think it works fine
V**-1 concern old habits risk falling in to old habits of not using when stressed
V**-1 concern Slow process Slows down development process.
V**-1 concern Think Tfind It's fit the way that we work.
V**-1 concern Time It takes long time when new to it because it is another way of thinking than you are used to.
V**-1 concern Time Consuming Requires good unit testing skills to create more scenarios as this becomes essential for TDD
W****-1 concern Too many problems are glossed over until a latter step.
W****-1 concern Like our coding standards, this too seems like something that'll be ignored before too long because management will want more code faster.
W****-1 concern We should be able to do trivial and easy steps in one step (probably with more use it will be less tedious).
W****-1 concern A lot of task switching between editors for tests/code
W****-1 concern More about pair programming: can't think when there are two people planning at the same time.
W****-1 concern Initially hard coding resulted in not realizing until later that we had shot ourselves in the foot in doing so. This was especially true when trying to recall what had been hard coded previously and what was already changed.
W****-1 concern It seems like we are initially writing code that we know will not be the final version (e.g., magic numbers, false/true returns).
W****-1 concern Taking this approach on a code base that takes at least several minutes to compile is a scary thought.
W****-1 concern What if the activists are as wrong about TDD as they were about DDT?
W****-1 concern Difficult to know where the line is between satisfying the current test, and employing a design that will satisfy the future tests.
W****-1 concern Difficult to think in small steps; tendency to want to do to much with each test which makes it more difficult to find problems when they occur.
W****-1 concern The length and possibly getting stuck backtracking to fix earlier solutions
W****-1 concern TDD is not for free. Two initial concerns: 1) Appears the designer will write twice as much code; so LOE will take twice as long? TTM twice as long? Mgmt may not always buy into this 2) Designers bad suppositions can get equally applied to the end-product software and test software. TDD doesn't catch this?
W****-1 concern Taking small steps tends to make initial code not handle cases you know will happen later down the line, such as wrapping in the circular buffer. I would think that refactoring code to handle this case would make the development slower because you have simple code first. The "advantage" however, is that adding the code to handle wrapping is tested by earlier simple test to see if something was inadvertently broken.
W****-1 concern Discipline to follow the tight increments of red-green-refactor can be difficult to master.
W****-1 concern I feel vaguely silly writing code that satisfies the tests that is not meant to be production code.
W****-1 concern Can increase development time.
W****-1 concern time to get used to
W****-1 concern Procrastinating the use of the correct logic is going to take some getting used to. How to apply this to larger systems is still unclear to me.
W****-1 concern I don't like that procrastinating is encouraged. If you know something is going to have to be done, I'd like to do it early to avoid the refactoring that ends up occurring.
W**-10 concern It concerns me that everyone doesn't do this.
W**-10 concern It feels painfully, awkwardly slow. It's hard to work in such small increments.
W**-10 concern The time it takes to do it up front (and how long to become proficient at it)
W**-10 concern Not always clear what is the smallest thing to change
W**-10 concern I'm wondering how I can be sure I have a complete set of tests for a piece of code.
W**-10 concern how well does it scale for code with lots of 'system calls'
W**-10 concern I'm worried that other people in my organization will complain about 'all the extra code' -- I don't think its non value added, but...
W**-10 concern How to rectify the 'small focus' of TDD with the 'big picture' of what you are building.
W**-10 concern I'm concerned at how this will scale to code that interacts with legacy code.
W**-10 concern how hard it was to maintain discipline, and not jump ahead to how I "know" the code should be.
W**-10 concern Explaining to project manager why its taking longer.
W**-10 concern When it came time to implement the circular buffer it was apparently necessary to change a lot of code at once with the inevitable chaos. I thought this was the thing TDD was intended to prevent. But this was a very simple problem. I assume much worse thigs are possible in real life.
W**-10 concern I like having the 'safety net' -- It feels empowering, but I'm worried that others will view it as weight and overhead for little value.
W**-10 concern speed. time spent running tests I know will fail and writing (even simple) code that I know isn't correct, slows things down. I do trust (i think) that this slow down more than pays off, but it is a concern nonetheless.
W**-10 concern Explaining to project manager why its taking longer.
W**-10 concern How much work the 'metal' level interactions will add.
W**-10 concern Will it always be possible to break down a complex code into those initial simple tests?
W**-11 concern My concern is that I may just as well have a bug in my test and a corresponding bug in the code that makes it pass.
W**-11 concern Writing code purely to make the test pass, that you know is going to change almost immdediately
W**-11 concern it seems like getting a whole to team to consensus on how granular to work could be problematic and distracting
W**-11 concern Feels like there was a lot of overhead switching files and building things I knew would not work.
W**-11 concern It is good for the new development. But not sure how can this be applied on a legacy code. additionally, for projects which have already running on a planned timelines and if we want to introduce TDD on them
W**-11 concern Interactions with other components. Dependency on other components.
W**-11 concern The simplicity of the implementation not focusing on corner cases
W**-11 concern A really different way to think and work. Needs a lot of practice to get used to it.
W**-11 concern Losing sight of end design while adding it in little bits
W**-11 concern I think is hard to have the patience specially if you are in a hurry.
W**-11 concern I followed from the starting point and completed the exercise. The note at the end suggested making the implementation reentrant to allow for an interrupt. I've done this before using pointers. How would you approach a refactor like that with TDD, change everything until the tests pass? or re-write the module using TDD?
W**-11 concern It feels a bit slow (although you probably make up that time in looking for bugs later on)
W**-11 concern Due to the frequent jumps between files, it gets a bit confusing
W**-11 concern Its not really a concern, but it feels slow.
W**-11 concern I may skip some safety feature since my test doesnt require it to pass.
W**-11 concern Very hard to not to develop a more complete functionality at once. I usually have a more clear view of what I want to implement.
W**-11 concern Sometimes new tests that pass, and I didn't necessarily expect them to.
W**-11 concern Longer time to first result.
W**-11 concern Some aspects may be hard to test,realtime behaviour How to fake interrupt latency, prioritaxion etc
W**-11 concern Getting buy-in from developers. Some argue that you cannot 'test' quality into your code, it has to be designed
W**-12 concern It would have been useful to be able to step through the test as it was not always obvious where I was stupid
W**-12 concern The initial amount of time to get up and running.
W**-12 concern It detracted from the final goal; instead of creating a circular buffer we created an array and then a linear buffer and then a circular buffer.
W**-12 concern Selling the idea to management
W**-12 concern Sustaining antiquated code with TDD.
W**-12 concern - It will be difficult to stay consistent and always use the TDD approach
W**-12 concern It causes no reason for concern as far as I see
W**-12 concern wrong premises for the tests will give wrong code
W**-13 concern While it's good that we attack one functionality at a time, we may loose some coding efficiency (i.e., doing multiple things in one scoop)
W**-13 concern In a more complex class with many methods, is there a potential for the coder to forget about some temporary code? There appears to be an assumption that unit test cases will cover enough variations of test scenarios such that all bugs will be covered.
W**-13 concern Speed of development.
W**-13 concern No real concerns. I'm not sure that forcing compile errors and link errors are useful. However, verify pass/failure of the test is.
W**-14 concern Way, way too slow. It is tedious to have to keep refactoring the source code when I already know what corner cases that I need to handle.
W**-14 concern Adding too much development time.
W**-14 concern Unable to identify the unneeded logic. The temptation is to think ahead and write the code for problems we see coming far ahead.
W**-14 concern It seems tedious for simple things
W**-14 concern The amount of time that would be required to use TDD.
W**-14 concern if you forget to test something but all tests are positive, might give the wrong impression that code is correct, also hard to always do small steps
W**-14 concern Steps very small. Often implementing things that are obviously wrong. potentially inefficient?
W**-15 concern Discourages thinking ahead
W**-15 concern Time-intensive overhead of hard-coding failures and pass cases prior to doing actual work.
W**-15 concern I wish it was quicker to implement and more widely adopted.
W**-15 concern Not convinced that it's worth all the extra work.
W**-15 concern Integration, threading tests, etc. As with all developer-driven testing, if I don't think of it, I'm not testing it.
W**-15 concern the incremental module development seems to be only as effective as the test case development.
W**-15 concern It seems like you have to really know what to test, and I feel like you're equally likely to simply forget about a corner case and not add the fix as you are to simply not add a test for it, which seems to defeat the whole point. In the end you still have to realize that problem conditions exist.
W**-15 concern Time consumption
W**-15 concern I'm still unsure about how I would apply this to legacy code
W**-15 concern Though I like the idea of using CPPUTest, the methods prevented here seem too long and impractical and tedious to use on a daily basis, especially on simpler problems. I can't see myself using it on a regular basis
W**-15 concern It seems like it just shifts the issue from writing bad code to bad tests. It doesn't seem like it's going to stop me from making mistakes, only change their form
W**-15 concern It seems like the mentality and tools are more useful / practical than the methods and process themselves.
W**-15 concern I feel like a lot of my work can't be tested with tests like this. It seems dependent on specific values and booleans and lots of my work doesn't necessarily rely on code that can be prove "correct" with values like that.
W**-15 concern I really don't feel like I actually solved the problem. It was so long and so abstract I can't tell if I'm still missing something.
W**-15 concern Personally I feel like solving the "hard part" and then testing that and letting the rest of the code and tests stem from there is more effective.
W**-15 concern I feel like doing this in reverse where you add a small change to the production code, then add tests to make sure it does what we think, then going back and refining when there are failures, is more intuitive.
W**-15 concern Impact on velocity of agile sprints.
W**-16 concern Having test which don't test what I think they do
W**-16 concern It felt "unorganized", for a lack of a better word; it was harder to keep a mental picture of what I was writing
W**-16 concern How do you do this with Already existing projects?
W**-16 concern Application to existing code bases. My own lack of discipline to following the steps.
W**-16 concern It is a new way of thinking that requires time to adapt
W**-16 concern Knowing what tests are needed at what time.
W**-16 concern Getting used to the process.
W**-16 concern The process does not feel intuitive, even though it seems to work.
W**-16 concern It requires more time than start testing with the embedded system debugger.
W**-16 concern I like tests but I often I prefer to test as much as possible with a minimal number of test cases/functions. Refactoring will be time consuming if there are lots of "trivial" tests.
W**-16 concern I am not sure how this all works when interrupts come into the game.
W**-16 concern I not sure how much extra time this will take.
W**-16 concern Team members not accepting the true results of the test. eg. There code does not pass the test and saying that the test is wrong.
W**-16 concern It's easy to get pulled forward thinking something like "hmm, if I add that variable of that type it means I have these limitations I need to consider..." and in this exercise I felt like sometimes I'd have to leave those thoughts because they went outside the scope
W**-17 concern It can be difficult to get a team of developers to follow TDD.
W**-17 concern Testing nondeterministic behavior seems difficult with TDD. E.g. - I want to test that a control system is stable (no oscillations) given some time-series test data.
W**-17 concern Are there some kinds of programming errors that cannot be revealed with tests? Thinking about memory allocation and multithreading in particular.
W**-17 concern - To implement a hardcoded value and forget to find a testcase (and so forget to test it that this was only a hardcoded value). - I dont know if it is the richt way to write first the code to pass the test as simple as possible and refactor it afterwards to a coding standard - To designe a test for every task, espacilly in case of special hardware dependencies.
W**-17 concern - It feels like we are maintaining two programs, it's a bit tedious - What if the tests are not correct? Who tests the tests? - If a new test adds, say a new return value type, shall we refactor old tests?
W**-17 concern VERY EASY to get ahead of yourself. Need to keep reminding yourself to hold back, PROCRASTINATE! Remember Beck's simplest possible thing mantra. Easy to let tests get too much duplication if you don't ruthlessly refactor on green. Big concern is maintainability of tests, avoiding brittleness that requires reworking tests because implementation changed something under the covers.
W**-17 concern concern 1105, and this too!
W**-17 concern concern 1128
W**-17 concern concern 1133
W**-17 concern concerned on friday about monday
W**-17 concern 931
W**-18 concern concerned Seems chaotic to write code that will you know will clearly fail tests later on. Seems that you could approach the problem holistically instead of ignoring your technical debt.
W**-18 concern dynamic languages I find C/C++ difficult, coming from a dynamic language background, but I understand that you're focused on embedded systems.
W**-18 concern gaps Applying tests to the API may be a real artform and I'd be concerned about hiding failure through poorly scoped tests.
W**-18 concern legacy Adding tests for new or existing functionality in code that was not at all written with TDD in mind.
W**-18 concern misleading TDD gives a misleading of security that the code is safe. Any missed test cases will lead to buggy. This approach is only testing the expected outcomes, the code could be doing far more or not enough.
W**-18 concern more bascis Probably need some more low level background information. The basics, like what are all of the available test macros, how can it be targeted in different development environments.
W**-18 concern overwhelmed I wish we started with a much simpler code.
W**-18 concern overwrought - Writing templated wrong code to end up rewriting right code. - the design follows the test
W**-18 concern scaling How to test more complex functionality (say implementing an FFT) - it seems difficult to break that into as small of chunks. Is a result test the way to start?
W**-18 concern unplanned Perhaps a false sense of security if you "just get the test to pass".
W**-19 concern Changes When can I do changes without writing a test? What criterions are there?
W**-19 concern Mess? Sometimes I start making a test pass and suddenly more and more tests fail ...
W**-19 concern More At first, it seems like a lot of extra code to write
W**-19 concern overlook Using hard coded values to quickly pass a test. It felt like cheating, and I was nervous that I could forget to fix that later and let the hard coded value into production code.
W**-19 concern Time Time to get code written. BUT.... that is partly inexperience, and you get the benefit of code security
W**-19 concern Tiny steps Small steps sometimes hard to reconcile with big picture.
W**-20 concern consuming It seems like a lot of extra work, which increase development time.
W**-20 concern drivers How can we use TDD to create microcontroller driver code? Is this possible, or is all of the TDD code just for business logic? Subtle bugs in driver code can be really hard to track down.
W**-20 concern fake That you should fake until you make it. I am used to think carefully before I implement anything, so when I implement it should be close to the finished code, not a fake code.
W**-20 concern new It goes against the grain of doing it the other way for many years
W**-20 concern rework Am I wasting effort refactoring code that I *KNOW* is wrong in the long run (like with hardcoded values)?
W**-21 concern atypical Doing minimum to pass test - what about best practices? There are things you "should" do that require a certain amount of overhead structure to create good code. Seems to skip that by just gettingby
W**-21 concern challenge How to implement in our Projects ?
W**-21 concern change control How to avoid missing any cases? What happens when a component is developed according to a requirement using TDD and then the requirement changes?
W**-21 concern double code size write twice as many lines to make it working
W**-21 concern Extra effort Bit of extra effort to write much more lines of code for testing compared to actual developed code.
W**-21 concern headers The step of adding the function prototype to the header file makes the feedback cycle slower than I'm used to. Normally in the languages I work with, get to a running but failing unit test faster.
W**-21 concern Integration How can we integrate TDD with different Requirements?
W**-21 concern More Code Lots of test code needs to be written
W**-21 concern None No concerns so far.
W**-21 concern predecessor Implementing it against an already established code base
W**-21 concern TDD FrmWrk + DevTool During actual development projects, we should have common platform for development and testing. I have concern that how to integrate test-frame work for TDD in actual development tools.
W**-21 concern time consuming time consuming need to write code with knowing that it will be scrapped later
W**-21 concern Time Consuming It slows down development and may affects the deliverable
W**-21 concern Unsure Didn't get to finish lab so not sure if there are others. Stuck at malloc area...
W**-22 concern Does not fit how I code. how to apply this to driver code that interact with hardware
W**-22 concern Does not fit how I code. Old leftover "test" code is left after testing. Must have a more comprehensive testing to ensure all avenues and old test code is checked.
W**-22 concern Hard to think of the tests in more complicated systems, where functions cover a lot of functionality it can be hard to create tests for.
W**-22 concern Hard to think of the tests Sometimes it might be difficult to come up with a test case that would target an edge case or part of the function that I'm trying to test
W**-22 concern Hard to think of the tests how not to over think or over design
W**-22 concern Hard to think of the tests if i hard-coded everything then forgot some test cases to check it
W**-22 concern None organizing the volume of produced tests
W**-22 concern Other. I have a good feel for how this works on a micro level with functions/classes. I'm curious how it would work on a higher system level with multiple components integrated together.
W**-22 concern Too much test code. This seems to add a lot of upfront time. I understand that this helps with having more bug free code in the long run, but for simple code, it seems like overkill.
W**-22 concern Too much time. This can be very time consuming if the code will not be re used
W**-22 concern Too much time. It is not the most fun way to write code.
W**-22 concern Too much time. Time commitment and adapting to changing requirements
W**-23 concern All the above. I'm concerned about the development time if we are going to do that for every module in my systems. But what about maintaining already developed code? How to deal with the hardware?
W**-23 concern Hard to think of the tests Thread safeness is hard ensure with TDD
W**-23 concern Other. hey 1023
W**-23 concern Other. It really requires self dicipline to write those minimal, not-functional-but-make-green-test implementations.
W**-23 concern There is no design. Lack of scope as the function unrolls; potential for necessary re-do of functions
W**-23 concern Too much test code. I'm concerned that tests written during TDD will have some overlap with acceptance tests. Test duplication...
W**-23 concern Too much time. sloooowwww and you have to limit your self not to code away... all my managers are concerned about extra time..... I dont know yet
W**-23 concern Too much time. test 1
W**-23 concern Too much time. test 2
W**-23 concern Too much time. test 3
W**-23 concern Too much time. test 4
W**-23 concern Too much time. test 5
W**-23 concern Too much time. fjsdfljhsdflijsh
W**-23 concern Where are the requirements? When should I move on from testing interfaces into the internal implementation?
W**-23 concern Where are the requirements? Sometimes unsure whether or how test implementation details. e.g. static or dynamic memory allocation
W**-23 concern Where are the requirements? Tests driving functional correctness without addressing qualities such as performance.
W**-24 concern All the above. I need to better visualize how this can work in Embedded applications
W**-24 concern All the above. Breaking a small behavior seems streaight foward, but how about breaking a complex system into small test concerns me.
W**-24 concern Does not fit how I code. novice programmer, so I often don't intuit good interfaces, but that comes with experience, and hopefully the testing forces the issue!
W**-24 concern Hard to think of the tests I feel like its easy to get ahead of yourself and then have gaps in the testing.
W**-24 concern Hard to think of the tests Test code can also lead to possible errors when the target implementation is not fully exercised or understood
W**-24 concern Hard to think of the tests Kind of lost when started in the test environment coding.. may be need to spend more time here
W**-24 concern None A lot of time is spend waiting for the compiler to discover that I forgot to define/declare a function.
W**-24 concern Other. Some types of requirements may be difficult to verify this way, particularly multi-threading issues with lots of asynchronous randomness.
W**-24 concern Other. My concern is that the test code now has to be maintained as well.
W**-24 concern Other. By willingly implementing only specific pieces at a time, it may be difficult to know when to implement the proper functionality, vs. just enough to pass the test.
W**-24 concern There is no design. Fit this simple problem well - will it fit more complex problems requiring more complex design decisions?
W**-24 concern There is no design. Bertrand Meyer: "No serious engineering process can skip an initial step of careful planning. It is good to put limits on it, but irresponsible to remove it."
W**-24 concern Too much test code. Forging ahead and not taking time to remove duplication
W**-24 concern Too much time. The speed (slow), or the perceived speed to get to a working FW.
W**-24 concern Too much time. It takes some time to write the tests and it might not be easy to see how much time of debugging it saves me.
W**-24 concern Too much time. way too slow
W**-24 concern Too much time. way too slow
W**-24 concern Where are the requirements? Wasn't clear where I was headed - should have read through all the test names first
W**-24 concern Where are the requirements? Simple implementation existed for a long time, needed a specific test to cause it to change (IsEmpty using index comparison instead of count).
W**-25 concern Does not fit how I code. TDD feels unnatural and seems like it will kill being "In The Zone".
W**-25 concern None Overhead of testing framework.
W**-25 concern Too much test code. We would spend more time writing test code.
W**-25 concern Too much time. More time for development
W**-25 concern Too much time. This could become tedious. The rejoinder to that is obviously "so is hunting and shipping bugs". I'd have to do this for a while before deciding, but my first impression is not uniformly positive.
W**-25 concern Too much time. Slow built times == frequent interruptions when trying to get into a "flow".
W**-25 concern Too much time. it could be simulated env but it's slow
W**-26 concern Hard to think of the tests Concerned I won't come up with tests to cover every case.
W**-26 concern None none
W**-26 concern None None
W**-26 concern Other. As far as TDD itself, no concerns. I do see the need to ensure that I have a bit more experience with hands-on programming but I'm eager to learn the good habits sooner rather than later
W**-26 concern Other. I don't have concern about concept of TDD. maybe this is slow way of working if there is Super man. like who don't need fast feeback because no mistake.
W**-27 concern Hard to think of the tests Sometimes, I got a feeling of writing more code (involved into requirements) and starting to think ahead and confusing actual test I need to write.
W**-27 concern None None
W**-27 concern Other. So far we have used cyber-dojo. How do I integrate CppUTest or another tool to a current project?
W**-27 concern Too much test code. Lots of tests could be hard to maintain.
W**-27 concern Too much test code. Can get a little carried away and add 'too many' tests. Some of them might not add any value, need to be careful with that
W**-27 concern Too much time. TDD seems to take a fair bit of time to develop as you have to make the design fail first then pass.
W**-27 concern Too much time. Integrating to a old project with a lot of dependecies.
W**-27 concern Where are the requirements? Not a fan of writing false positives. As the API gets written in test more, those false positives turn to true negatives, but I'm not sure that this work may be done fully.
W**-28 concern Hard to think of the tests You have to think of all the failure modes. A test will not catch corner cases you didn't think of.
W**-28 concern None I already try and use TDD so I am already a bit biased so not a lot of concern, but I do tend to write multiple tests and then go implement a chunk of them instead of one test at a time
W**-28 concern None How can this work with hardware dependent code?
W**-28 concern None How can this work with hardware dependent code?
W**-28 concern None How can this work with hardware dependent code?
W**-28 concern Other. That certain parts of embedded development would have a hard time utilizing TDD
W**-28 concern Other. Strict TDD emphasizes one step at a time when experienced programmers may be able to at least combine one or two steps.
W**-28 concern Other. lose confidence when something is "done"
W**-28 concern Other. It's hard to not want to get ahead of yourself during implementation
W**-28 concern Other. When I don't know how to test something, e.g. dynamic memory allocation.
W**-28 concern There is no design. I thought we were going to be using C++ seems a bit tedious and interferes with the flow a bit
W**-28 concern There is no design. Perhaps if you have a specific design or implementation in mind, it might "prevent" you from using that? (Perhaps, TDD will help you find a "better", simpler one).
W**-28 concern Too much time. I am concerned that taking the time to do each of the TDD steps will take up too much time.
W**-28 concern Too much time. I am concerned that taking the time to do each of the TDD steps will take up too much time.
W**-28 concern Too much time. it may take too much time to complete or think of enough tests before a scheduled delivery to a customer, for example.
W**-29 concern Does not fit how I code. Doing this methodology will take time for me to adapt efficiently to development. Not the coding aspect, just the mental approach to not add stuff I foresee I need early on.
W**-29 concern Does not fit how I code. It seems a bit dogmatic in it's approach. Do I really need to make every test fail first?
W**-29 concern Does not fit how I code. Having the tests written in advance means I can think about coding and not what the tests should be. I can see this works well with pair programming. How about without a pair?
W**-29 concern Hard to think of the tests Should you write a test for everything?
W**-29 concern Hard to think of the tests How can I be confident that I've thought of all the tests? If I develop with hard-coded values and deliberate mistakes as part of TDD, I need to know the tests are strong enough to catch those.
W**-29 concern Other. Well, I was pretty lost right at the beginning, so there wasn't much I could do to proceed. Of course, this is a limitation on my end...
W**-29 concern Other. Well, I was pretty lost right at the beginning, so there wasn't much I could do to proceed. Of course, this is a limitation on my end...
W**-29 concern Other. Deliberately writing a naive implementation (with hard-coded values etc) makes me feel like, if I take a break and come back, I'll lose the thread of what I was doing and forget to clean up.
W**-29 concern Other. Hard-coding the implementation to make the tests pass feels morally wrong (this eventually wears off?)
W**-29 concern Too much time. A LOT of iteration.
W**-29 concern Too much time. A LOT of iteration.
W**-29 concern Too much time. Getting to the first passing test for a new embedded target can be time-consuming.
W**-30 concern Does not fit how I code. The concept is new and I have to change my whole prospective of writing code. Whatever I have learnt/worked on is now redundant with this concept
W**-30 concern Does not fit how I code. my concerns that if will i continue doing this approach in the future or not
W**-30 concern Hard to think of the tests As we face more complex code bases, how can we anticipate the scenarios to test for and how do we incorporate a test harness in already well established systems?
W**-30 concern Hard to think of the tests Writing the test cases might be harder than satisfying them. It might be difficult to break down the problem in such small increments in some unfamiliar domain scenarios.
W**-30 concern Hard to think of the tests I'm concerned that I might miss things in the test-setup.
W**-30 concern Hard to think of the tests I am quite concerned it will not be easy for me to write the "silly" test I wrote at the beginning. Than everything get easier.
W**-30 concern Hard to think of the tests I am quite concerned about taking a long time to get used to TDD as I have taken a long time to code few lines
W**-30 concern Other. my concer is that I look stupid
W**-30 concern Other. When I am doing it allone, it's sometimes hard to come up with a decision.
W**-30 concern Other. Spending too much time in the incremental code construction that I might forget some hard-coded values later on.
W**-30 concern Other. Integration of unit-testing sw with current toolchains...
W**-30 concern Too much test code. This is probably just because this is a first time use, but writing so many tests for such simple scenarios seems like it would get impractical with more complex systems.
W**-30 concern Too much test code. How do I fit all this test code into my embedded development?
W**-31 concern All the above. Some of the steps are so small that they break up my train of thought. TDD seems to discourage design and thinking ahead.
W**-31 concern Does not fit how I code. It is a bit hard not to write the code before the test. It may take awhile to get used to it.
W**-31 concern Does not fit how I code. Need to change your mindset
W**-31 concern Does not fit how I code. It was hard to write such small pieces of code, knowing that I would have to change it again in a couple tests later.
W**-31 concern Does not fit how I code. Can I write tests with real hardware inputs rather than hardcoded values?
W**-31 concern None Nothing really
W**-31 concern None (Lack of) Acceptance by other embedded programmers.
W**-31 concern Other. I don't fully understand how to utilize the create/setup functions yet to ensure I'm testing the proper things.
W**-31 concern Other. Though the approach is structured, I feel very tempted to make shortcuts, even if I logically believe they'll save time down the line.
W**-31 concern Other. I wonder how to communicate the shift in time investment (more time to complete stories during sprints, less time testing) to upper management that may not understand TDD, even if the dev team does
W**-31 concern Where are the requirements? TDD seems to promote "hacking" at the problem instead of thinking about the requirements.
W**-32 concern Does not fit how I code. Your trap for extra functionality was brutal. Some times it was easier to do the right thing than to fake it.
W**-32 concern Hard to think of the tests It relies heavily on how well you write your tests
W**-32 concern Hard to think of the tests Writing tests could be difficult.
W**-32 concern None Overlooking test cases. Accidentally leaving 'false positive' results in refactor.
W**-32 concern Other. Well because of the narrow scope on a singular test, it can make anticipating future problems harder. Kinda seems like a you are reacting to the test rather thinking about what could go wrong.
W**-32 concern Too much time. It seems ideal for code you are starting out writing yourself, but seems like it could get challenging to get it up and running at first for a huge code base you inherit.
W**-32 concern Too much time. TDD can take longer to code in the early stages of a software project, and some of the benefits only become apparent in the maintenance portion of the software development process
W**-32 concern Where are the requirements? Seems like a silly question: the test cases should have been formed from the requirements, I assume.
W**-32 concern Where are the requirements? Sometimes it looks a bit daunting if you have a lot of code to write.
W**-33 concern None I find it too easy to skip the "test fails" step
W**-33 concern None None so far.
W**-33 concern Other. some of the error messages are not that easy to decode (I am sure this will come with practice though)
W**-34 concern Does not fit how I code. Not intuitive to keep it simple, tended to keep "jumping ahead" in the process and coding too much.
W**-34 concern Does not fit how I code. After coding for 35+ years, it's hard to not think ahead and write code I know I will need eventually before writing the test for it.
W**-34 concern Hard to think of the tests writing the test cases does take longer on the front end, though it should save time in the long run, can also be hard to come up with test cases
W**-34 concern Hard to think of the tests The number of tests needed could be difficult to estimate when sizing the effort.
W**-34 concern Hard to think of the tests Trying to think of every test case as the code is being written seems difficult
W**-34 concern None Not many, I like it, just need to sharpen up on my C for your course. :)
W**-34 concern None I had one concern before we start: How to convince colleagues to get into TDD. But now I'm sure that if they take this course, they will love it too.
W**-34 concern There is no design. Forces me to fail. If I have done this in the past, I see the pitfalls, and I know how to structure this properly, it still forces me to code like a fresh college graduate.
W**-34 concern Too much test code. It can lead to bloated code security holes may be introduced
W**-34 concern Too much time. Too much time to continue writing test cases before writing applicable code.
W**-34 concern Too much time. Is looks like time consuming effort to test over and over the code that is not yet finished.
W**-34 concern Too much time. As we just experienced we could have wrote the code more efficiently ( think about the capacity in the beginning).This approach seems at least to me,to make you move slower.
W**-34 concern Too much time. Scheduling time for setting up tests.
W**-34 concern Too much time. The iterative process seems very time consuming
W**-34 concern Too much time. It will take more time on coding the TDD code, if time is urgent to finish implementing all the needed features.
W**-34 concern Too much time. More time required to work out than by just coding alone without any testing. Understand that this is time saved overall, especially if a bug is prevented from appearing later on.
W**-7 concern Puzzled it has never become the norm in software development.
W**-7 concern how we can integrate legacy code to TDD?
W**-7 concern It may need a lot of interactions for simple things.
W**-7 concern that it will be hard to start to implement when the project is in an advanced stage
W**-7 concern So far, it seems a little difficult try to figure out how to apply the knowledge in the daily development
W**-7 concern increase of development time.
W**-7 concern Well, in the previous point my concerns was that the a bad test can lead a bad development, because in order to pass the test the development is driven to be very bad. Second, I sense that maybe the development can not foresee future problems while developing, because maybe the test is not going to test it.
W**-8 concern Not thinking of all test cases (not unique to TDD, but it's a concern); doing design "on the fly" (accustomed to thinking of functionality, then designing API, then writing code, then writing tests against API), not making up API as I go
W**-8 concern When do you know you have written sufficient test cases? Setting up test environment to mimic target processors.
W**-8 concern The underlying system. How do I make such detailed tests on a embedded device ?
W**-8 concern ROI on up front time invested vs back end time invested. I think this is simply a case of not enough exposure to TDD.
W**-8 concern none
W**-8 concern I am concerned about maintaining tests through API changes (for example, adding a new argument to a function.
W**-8 concern That you can get code to work that is not really what you want in the end, needs refactoring?
W**-8 concern I worry that I will write the wrong tests: too many, too few, or testing the wrong things. I fear that I'll pin myself down to implementation details instead of the desired result.
W**-8 concern perception of moving slowly
W**-8 concern The approach I've seen so far will not save me time but cost more time if I take the approach as-is.
W**-8 concern It's gonna take a while to wrap my head around this way of thinking...can an old dog be taught to sit? And I wonder if it can be applied in ALL scenarios. Writing operating systems for instance.
W**-8 concern I am concerned with habit reforming for more senior level developers to adopt this process, and the learning curve of onboarding any level developer.
W**-8 concern I understand the concept of DTSTTCPW, but I'm not sure I agree. I understand we're trying to break down the complexity into smaller manageable chunks, but it seems like more work to write code we know to be incomplete/incorrect in the name of TDD, rather than to go to the inflection point on the analysis paralysis curve and drive to done as quickly as we can. Why is it a bad thing if we pass multiple tests with code we wrote very quickly? As long as we have good tests that fully test our software and they pass, isn't that sufficient? Extra cost: Still not sure (and scared of) how we're going to abstract hardware-specific features (timers, IRQs, etc.).
W**-9 concern not much design involved
W**-9 concern It is easy to get a false sense of confidence, thinking that you've thought of everything, and then get surprised by a real world case that you hadn't considered when writing your tests.
W**-9 concern Difficult to write tests that incrementally grows the solution
W**-9 concern It can be too granular, or people can be too granular when using it. (Testing constructors/getters/setters/generated code/frameworks etc.)
W**-9 concern so many small steps.
W**-9 concern Too fragmented implementation view?
W**-9 concern More code to keep readable and clear
W**-9 concern scaling to work with complex systems
W**-9 concern If you forget to test something it can be hard to find the error.
W**-9 concern The interface might not be clear at start.
W**-9 concern It's definately taking much longer to write this circular buffer code than those I've written recently Still not sure how it would work with hardware such as decoding from a GPS chip etc
W**-9 concern TDD can give robust code, but there is still no guarantee the code actually does what you want it to do at the system level
Z****-3 concern to get ahead of ourselves... implement too many things at once
Z****-3 concern it concerns me that this is nice when making code from scratch, but when we have to go in and modify existing code, this approach feels like it might not translate as well? perhaps? i guess ill have to try it out
Z****-3 concern Requires you to remember a lot of different points in the code and the forced failures and passes to prove a testcase can make it more confusing when developing additional testcases
Z****-3 concern My main concern is that when there is a deadline coming quickly, I may be unable to use TDD properly.
Z****-3 concern Takes extra time upfront (but saves time and money later). When a quick implementation is required will management wait for us to write test cases?
Z****-3 concern So far, so good.
Z****-3 concern A little too granular - would like to do a little more coding between tests.
Z****-3 concern You can end up testing the code or the engineers interpretation of the requirement, and not necessarily the correct interpretation of the requirement.
Z****-3 concern no guarantee that tests are thorough
Z****-3 concern If you don't write enough tests your implementation may still be incorrect even though all your tests pass.
Z****-3 concern It seems that it easy to generate inefficient or sloppy code.
Z****-3 concern seems to take forever to code a simple routine because of the testing. maybe that's the point
Z****-3 concern Just wonder the test framework covers all possible test scenarios.
Z****-3 concern Doing test/code development in small steps iteratively, could increase the development time for large designs
Z****-3 concern I would really hate to perform TDD on our Parameters component. I would also think that this method would impact our project schedule
Z****-3 concern not sure how to apply it to our existing code base. maybe applicable to a new clean development??
Z****-3 concern
Z****-3 concern Under time pressure, I could see skipping TDD and falling back into regular development.
Z****-3 concern Overhead. encourage focusing on the details before solidifying the overall design. (Risking loosing prospective of the 'bigger picture')
Z****-3 concern Discipline to start getting used to TDD Define the right test cases for just function you need it would be a hard skill to master
Z****-3 concern If tests are not well thought out, some requirements/use cases could be missed out
Z****-3 concern doesn't keep you focused on the whole problem, but on the test instead
Z****-3 concern TDD can drive you to build a component out of order. For example, if the test for the "roof" comes up before the test for the "walls". I can end up building out of logical order, and end up doing things more than once.
Z****-4 concern sometimes the tests took more time then the simpler parts of the program.
Z****-4 concern Takes a lot of time
Z****-4 concern It feels like a hindrance when you have a clear idea of what needs to be done, but are forced to test what seem to be obvious things.
Z****-4 concern it may lead to short sightedness and smaller bit by bit coding than is efficient
Z****-4 concern This is very useful for a well defined small class but I am not sure how I can apply this at a high level functional test of a system
Z****-4 concern Stubbing out implementations felt a bit slow/tedious.
Z****-4 concern The total time to complete the functionality was larger because I was creating tests as I was developing the functionality.
Z****-4 concern How TDD can be used for legacy code???
Z****-4 concern Can take a lot more time.
Z****-4 concern Might consume more time at the beginning and also if design changes, you might have to come back and modify the test cases.
Z****-4 concern Sometimes the oversimplification confused me more.
Z****-4 concern Takes longer to write code because you are constantly rewriting functions
Z****-5 concern too long
Z****-5 concern It takes a bit longer during development. Leaving initial bugs or failures that I know exist.
Z****-5 concern Getting used to C++ tests and dev
Z****-5 concern If you write the test wrong, the code will clearly turn out wrong.
Z****-5 concern Understanding what the unit test is supposed to accomplish can be up to interpretation (buffer vs queue and if a test should pass/fail or expected behavior).
Z****-5 concern I still dislike the general approach to starting with TDD, because I find it hard to adapt to less simple problems. All examples I've seen all use data structures or math algorithms because they adapt well to this scheme.
Z****-5 concern If you follow the process exactly it seems like it creates a fair amount of extra busy work. It also creates more code requiring additional development time.
Z****-5 concern Can miss some tests scenarios and that can impact the product functionality
Z****-5 concern I'm concerned I (as a tester by day) will not know the most appropriate times to use TDD.
Z****-5 concern Not TDD, but struggling a bit with C++ slowed me down quite a bit. I suspect that what would burn you would be the thing you didn't think to test during development, or a late arriving spec change that invalidates prior test cases.
Z****-5 concern it does take extra time. Also what test harnesses are available? There is a 1 time setup involved
Z****-5 concern I feel that it MIGHT make some coding cases more difficult than they need to be. For this first hands-on example, I found it hard to write test code that I knew was going to be wrong in the near future, or to write function declarations that I knew were going to soon be obsolete. In other more difficult coding cases, I'm sure the process would be more efficient.
Z**-1 concern blinders Difficult to see the forest for the trees. Feels a little bit like finding bugs/pitfalls by falling into them rather than planning out a path between the pits.
Z**-1 concern careful If we don't have *all* the test cases written down (and implemented), I'm afraid that the result will be a mixture of TDD and Debug-later-programming, which might defeat the purpose.
Z**-1 concern Complexity "Will fix later" makes me uneasy. What if I forget? Feedback is great, but it seems we are maybe being encouraged to rely on it too much. It's already difficult to remember everything.
Z**-1 concern context switching Continuous context switching between code and tests.
Z**-1 concern Dangerous The idea that the test should first fail, and that other logic that is untested should be put off seems (even in this example) to lead to *deliberately* writing wrong code, however temporarily.
Z**-1 concern Efficiency Spending extra time on trivial cases. How to select which test and failure cases to try first.
Z**-1 concern granular I want to have a good understanding of the overall picture before coding. This granular approach let me go back and forth couple of times
Z**-1 concern granularity The cycle is a bit too granular for my taste. I think the number of required steps tends to distract more than help. I prefer to collapse some steps in my everyday work.
Z**-1 concern Hard to think of the tests I wrote bad code
Z**-1 concern Hard to think of the tests i am so worried
Z**-1 concern hesitate Hard to determine when I should follow TDD and when I should be confident in my programming skills and skip it for efficiency. Some functions are hard or expensive to design unit tests for.
Z**-1 concern integration It is not yet obvious how TDD scales to integration or system level tests.
Z**-1 concern less-coverage I felt like I had less confidence in my coverage, perhaps because I spent very little time thinking about a correct implementation.
Z**-1 concern longer Results in additional work to revise previous tests when the interface/design changes midway through the TDD cycle
Z**-1 concern not good enough what concerns me the most is that what if i don't come up with good tests?! also wouldn't it a lot more complicated when the function is way more complex?
Z**-1 concern practiciality It's not suitable for things which are highly difficult to test e.g. UI code
Z**-1 concern simplistic I can see how it could be adopted as a development strategy in this toy example of a CircularBuffer, but not sure how it would translate in more complicated scenarios?
Z**-1 concern slow 1. Development becomes slower 2. When I start with new tests, I may need to rewrite/refactor existing code.
Z**-1 concern slow The very small iterations are substantially impacted by the speed of the build, and make it easy to take a poor design path early in development. I prefer to write more tests up front.
Z**-1 concern Subjective Just because there are tests, it doesn't mean they are good tests.
Z**-1 concern triviality It seems unnecessarily trivial in many cases.
Z**-1 concern unease I felt uneasy not thinking as much about implementation, like I'd forgotten my keys or left the oven on.
Z**-1 concern Where are the requirements? this and that
Z**-1 concern Where are the requirements? this is it
Z**-1 concern Where are the requirements? you know it

Make this into a word cloud

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