What concerned 1091 people about their first TDD experience

Summary selected Impressions
concern: 851 concern 851, revised, again, one more time. and again
concern: ??? don't know
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)
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
concern: All the above. Could write some code for a test to pass in a simplistic way, forget about simplification and leave it there.
concern: All the above. In the real world, the code is much more complex, and usually, much time will not be there for coding. In that TDD takes some time to write test-cases and then code and then write UnitTest for it.
concern: All the above. How do we get started? What setup is involved in getting this to the starting point provided?
concern: All the above. This seems to be okay for new start.. how do you apply this to existing legacy code.
concern: All the above. Definitely not how I'm use to coding!
concern: All the above. We make progress only base on test, it look like we just move the time from debug to test. We do not consider further until we found it. just try and error
concern: All the above. some test case might miss and take much time.
concern: All the above. nothing yet.
concern: All the above. nothing yet.
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?
concern: All the above. I need to better visualize how this can work in Embedded applications
concern: All the above. Breaking a small behavior seems streaight foward, but how about breaking a complex system into small test concerns me.
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.
concern: All the above. increase of development time.
concern: All the above. It may be hard/very time consuming to test larger, "more undefined" modules/systems
concern: All the above. ı have some concerns about abstracting hardware dependencies
concern: applicable Is TDD suitable for any application / situation. For instance when code cannot be that modular.
concern: apply about how TDD should be applied.
concern: apply It's good. I'm not sure that I can apply it to my project.
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.
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.
concern: asdertyhju Building software under testing can treacherous; because it displaces thinking about state and persistence in code being written.
concern: asynchronous system I'm making the product rely on the asynchronous system, how can I write the unit test for that system?
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
concern: Awkward I already had a vision in my head, but implementing it in this manner seemed to slow the process and felt awkward.
concern: Awkward It feels a bit awkward and like it takes much more time than the usual way of coding
concern: Backwards It can be hard to figure out exactly what you have to test for.
concern: bad enfluence encourages bad development practices
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.
concern: badger It breaks up my global train of thought when making such small code increments.
concern: blind I want to use a debugger and step through my code. I can't SEE why it is failing
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.
concern: boundary Some boundary conditions are implementation specific, so hard to write test in advance.
concern: build-environment our build time
concern: Burdensome Additional time in projects to write all the unit tests and legacy code not written with TDD.
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?
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.
concern: case missing Takes too much time and can miss cases
concern: challenge How to implement in our Projects ?
concern: change defining the interface is difficult changing the test cases when the interface changes
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?
concern: Changes When can I do changes without writing a test? What criterions are there?
concern: Code coverage Can we achieve 100% code coverage by using TDD?
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!
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.
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.
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.
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.
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.
concern: confusion My concern about TDD is how to write full unit test case for my project which is maybe so complex.
concern: consuming It seems like a lot of extra work, which increase development time.
concern: context Currently i´m a bit thrown off by looking from two different contexts
concern: context switching Context switching when "cheat". I.e. thinking about empty, cheat, move on to full
concern: context switching Continuous context switching between code and tests.
concern: corner cases How do I know I get all the corner cases (by going step by step, I might miss the big picture).
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.
concern: Cover all cases Time spend to test Does the test cover all cases?
concern: cover all use-cases When do we know our test cases can cover all the use-cases?
concern: Coverage Getting the tests right seems critical. I probably overlooked something, but I got through the entire exercise without dynamically allocating the array.
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.
concern: coverage If a program has long and complex codes then how can test codes cover all cases?
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.
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.
concern: cumbersome In a deadline, i can see this process to be cumbersome to manage.
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.
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.
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.
concern: dependencies My concern is how to handle Hardware dependencies.
concern: dependencies How to make it work with complex dependencies.
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
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.
concern: dependency When module has a dependency of external environments such as network and server, how can it be include in test codes.
concern: Dependent Still dependent on me to think of many tests.
concern: design how to do design? no design in TDD development?
concern: design im worried that designing things for the short term will have large negative consequences later on
concern: design May lead me towards a design that I'll regret later because I didn't do as much upfront design work.
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?
concern: distracting Can be difficult to focus on good design/good refactoring
concern: Does not fit how I code. I am concerned that the extra time spent writing all the tests will prevent me from going back and improving/refactoring the code once the tests are passing.
concern: Does not fit how I code. It could be hard at first to keep the increments small and not to jump too far ahead of things.
concern: Does not fit how I code. Need the idea to be clear in advance
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)
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.
concern: Does not fit how I code. How do you apply this to target hardware and external inputs?
concern: Does not fit how I code. It felt like cheating to pass the tests before a "final" implementation existed.
concern: Does not fit how I code. What if your compiler takes a *very* long time to compile?
concern: Does not fit how I code. How does this method fit in and integrate with libraries and other people's code?
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.
concern: Does not fit how I code. Setting up the test harness to within a target environment.
concern: Does not fit how I code. Not sure how to plug-in a tdd framework in our platform (specific compilers, C-only, etc.)
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...
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?
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.
concern: Does not fit how I code. It might be difficult to always think of the all tests required before developing the software.
concern: Does not fit how I code. Initial time to adapt it into normal work, and will others use and maintain the unit tests.
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.
concern: Does not fit how I code. Not sure if this can be applied to testing an existing legacy code.
concern: Does not fit how I code. You need to do really one step after the other - even you would like to do several steps at once. First do the Test, then take care of only those tests.
concern: Does not fit how I code. I find it strange that I have to develop in very small pieces but I can live with it.
concern: Does not fit how I code. Will take some time to get used to.
concern: Does not fit how I code. Feasibility of ensuring no test code makes it into shipped product
concern: Does not fit how I code. Feasibility of ensuring no test code makes it into shipped product
concern: Does not fit how I code. The different way of thinking about each step of development and how to avoid doing to much at once. This provides good structure but slows down work a lot when you're unfamiliar with the process.
concern: Does not fit how I code. It is incredibly difficult not to think ahead or write code before we have a testing procedure for it. Forcing myself to adhere to the structure makes me worry I'm not being efficient.
concern: Does not fit how I code. I am concerned that is considered good practice to (initially) hardcode tests to pass/fail. Wouldn't it be better to draft test cases that are intended to be functional?
concern: Does not fit how I code. Implementation requirements for what I work on are not clear; details depend on me determining the caps. and limits of target platform while coding. My embedded hw lack resources or I/O to test well
concern: Does not fit how I code. It seemed that, during the training, we may be writing code just to let the test pass, but this code may be temporary and will be replaced later.
concern: Does not fit how I code. Intentionally not implementing the full (or even any) functionality is uncomfortable and seems prone to future errors
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.
concern: Does not fit how I code. Intentionally not implementing the full (or even any) functionality feels uncomfortable
concern: Does not fit how I code. Purposely writing code that is wrong. Not just stubbed, but wrong.
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.
concern: Does not fit how I code. It can be challenging not to get ahead of yourself when coding.
concern: Does not fit how I code. I need to think differently from my usual working style.
concern: Does not fit how I code. Scalability. This is a pretty simple exercise that is pretty cut and dry. how does this scale for more complex functions.
concern: Does not fit how I code. It can be annoying to intentionally write the incorrect implementation for the production code, simply because we don't want to "get ahead of the tests".
concern: Does not fit how I code. It's very methodical and requires developers to fight their instincts to start writing code that they know they'll need, in some cases by intentionally writing code that they know is wrong.
concern: Does not fit how I code. I watched the video about TDD with hardware dependencies, but I still have trouble visualizing how to best do this. I'm hoping future modules give an example to show how this process looks like!
concern: Does not fit how I code. Sometimes the test driven way feels like a context switch, making me loose mental state. I'm concerned it could disrupt the flow.
concern: Does not fit how I code. translate this into Visual Studio
concern: Does not fit how I code. Incremental testing may not fit for certain cases.
concern: Does not fit how I code. It requires discipline, some of the issues I have is that test cases are written after the fact, not as a way to drive the development.
concern: Does not fit how I code. I have to get used to narrowing the scope of the code I am testing and not moving too far ahead.
concern: Does not fit how I code. Hard to not jump ahead towards the final solution when writing code to pass tests.
concern: Does not fit how I code. My lack of understanding of C
concern: Does not fit how I code. I'm struggling with the mental discipline of not jumping too far forwards and implementing things that I'm not testing.
concern: Does not fit how I code. Writing the test before implementing functions is unusual to me
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?!
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.
concern: Does not fit how I code. Hard to carry out if something has to be adapted in legacy code.
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.)
concern: Does not fit how I code. Not yet sure when faking it is harder than writing the real thing
concern: Does not fit how I code. Theoretical approach that one has to get used to first
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.
concern: Does not fit how I code. Hard to get rid of old habits.
concern: Does not fit how I code. Requires discipline and a change in thought process and activities
concern: Does not fit how I code. I am not used to decomposing a module at this level of detail. E.g. with the circular buffer I pretty much know how it is supposed to work, so it is a bit tedious to force myself to go step by step.
concern: Does not fit how I code. A bit irritating in the beginning
concern: Does not fit how I code. As stating when registering we need 5-30 minutes to get new SW running. This does not fit to those tiny steps.
concern: Does not fit how I code. to much test driven .....
concern: Does not fit how I code. Slightly prescriptive test regime in terms of how it would cope with multi-threaded systems.
concern: Does not fit how I code. There are a lot of moving parts in our legacy code base - e.g. C/C++ intertwinded with some generated code. No point testing until we have done some minimum stitching etc.
concern: Does not fit how I code. how to apply this to driver code that interact with hardware
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.
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!
concern: Does not fit how I code. TDD feels unnatural and seems like it will kill being "In The Zone".
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.
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?
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?
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
concern: Does not fit how I code. my concerns that if will i continue doing this approach in the future or not
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.
concern: Does not fit how I code. Need to change your mindset
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.
concern: Does not fit how I code. Can I write tests with real hardware inputs rather than hardcoded values?
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.
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.
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.
concern: Does not fit how I code. Struggling with the WHY of the tight test-code-test-code loop. My natural inclination is to define the interface, then write the tests, then write the implementation.
concern: Does not fit how I code. It seems like it would be faster to write several tests at once and try and make them all pass at once for things all tied to one implementation feature rather than trying to add dummy code each step.
concern: Does not fit how I code. The tests are being passed using hard coding techniques that can be missed in refactoring code.
concern: Does not fit how I code. Seems slow-ish, backtracking, not "able" to make simple steps forward when you should.
concern: Does not fit how I code. Not particular how I code but how my coworkers code. How to integrade it into a team workflow
concern: Does not fit how I code. Not used to working in such small increments. Worried that I'll miss an important test or check.
concern: Does not fit how I code. I often forgot to follow the "fake it til you make it" paradigm and moved straight into the actual 'unfaked' implementation.
concern: double code size write twice as many lines to make it working
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.
concern: dynamic languages I find C/C++ difficult, coming from a dynamic language background, but I understand that you're focused on embedded systems.
concern: easy to skip tests you have to think about everything that can go wrong. Its easy to skip tests
concern: Efficiency Spending extra time on trivial cases. How to select which test and failure cases to try first.
concern: effort Concern that the additional up-front development effort could be significant
concern: Embedded Implementation to embed. systems with spec. libraries and multitasking apps using embed. OS.
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.
concern: expectations Trying to figure out what to test before you have a clear idea what you want.
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.
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.
concern: Extra effort Bit of extra effort to write much more lines of code for testing compared to actual developed code.
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.
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.
concern: faking Getting too good at faking it
concern: feels slow It FEELS it takes longer to accomplish simple tasks, causing some anxiety in terms of perceived progress.
concern: Force to write tests TDD force to write tests for expected results which has to be fixed.
concern: forget Forgetting a test case and, therefore, forgetting to properly implement a function with a "return true" type of temporary implementation.
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.
concern: gaps Applying tests to the API may be a real artform and I'd be concerned about hiding failure through poorly scoped tests.
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
concern: granularity Doing this iterative test and development at very low granularity can be conterproductive.
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.
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
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.
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.
concern: Habitual Hard to break coding habits
concern: Hard Hard, take more time to dev
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.
concern: Hard to think of the tests Clearly my development habits have to change to embrace this fully. I could see that I might go back to the old way of development if I get stuck.
concern: Hard to think of the tests It seems like TDD will not be effective if critical test cases are overlooked. Pretty much the same issue as testing post development.
concern: Hard to think of the tests Have the patience to use small enough test and increments when coding.
concern: Hard to think of the tests Tests need to be good because code is to pass tests. I'm unsure how this will work with large project.
concern: Hard to think of the tests Do i have patience not to cut corners when making tests and doing implementation step-by-step
concern: Hard to think of the tests May create a faulty feeling of confidence? Still requires the developer to come up with things like, for example corner cases.
concern: Hard to think of the tests Is it worth of the extra time spent? Can I be trusted to write tests that are correct?
concern: Hard to think of the tests too extra work
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
concern: Hard to think of the tests Not designing well the test or taking the wrong approach
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.
concern: Hard to think of the tests Difficult to perform procrastination.
concern: Hard to think of the tests Might be hard to think of test yourself
concern: Hard to think of the tests Figuring out how to write the correct tests
concern: Hard to think of the tests * Could consume a bit more time than necessary * Chance of redundant test cases * Is my coverage good enough?
concern: Hard to think of the tests Chance of redundant test cases
concern: Hard to think of the tests Is my coverage good enough?
concern: Hard to think of the tests How to cover all meaningful scenarios. It takes time to plan all tests.
concern: Hard to think of the tests Immense effort and analysis required to develop the test cases upfront
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?
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 :)
concern: Hard to think of the tests What if I forget to test something not so obvious?
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
concern: Hard to think of the tests Its a new way of thinking.
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.
concern: Hard to think of the tests Applying TDD on bigger functions or complex requirements
concern: Hard to think of the tests Time consumed for thinking and putting down the test, but I am sure its all fruitful, but new user its a big concern.
concern: Hard to think of the tests Test cases are limited
concern: Hard to think of the tests Test cases are limited
concern: Hard to think of the tests What if we miss identifing the test cases.
concern: Hard to think of the tests What if we miss identifing the test cases.
concern: Hard to think of the tests Writing test cases seems like it might be difficult without explicit guidance on how/what to test
concern: Hard to think of the tests The tests were written for me, how would I know what tests to write?
concern: Hard to think of the tests Difficult to know if you have tested everything you needed to.
concern: Hard to think of the tests If the requirement is unclear it can be hard to know what to test.
concern: Hard to think of the tests still working on the simple things, would like to see how to do TDD in complex code
concern: Hard to think of the tests I would not figure out some of the tests.
concern: Hard to think of the tests Not sure how it works for more complex parts of a code
concern: Hard to think of the tests It'll probably take some getting used to in order to come up with tests.
concern: Hard to think of the tests I can still fail due to lack of imagination. If I don't have tests for all possibilities, I KNOW that's the first thing a user will do!
concern: Hard to think of the tests Not sure how to implement the same when the code we are writing is close to the firmware. Multiple cards, multiple hw vendors, multiple threads, different communication interfaces.
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.
concern: Hard to think of the tests Since TDD is new to me it is a bit challenging to do it on the spot.
concern: Hard to think of the tests Code size may increase due to adding more test cases, and how to confirm full test coverage of a function/feature ?
concern: Hard to think of the tests Code size may increase due to adding more test cases, and how to confirm full test coverage of a function/feature ?
concern: Hard to think of the tests It's hard to think good test case.
concern: Hard to think of the tests Not every test is easy to achieve. For example, memory population is a hard issue to debug and write the test.
concern: Hard to think of the tests Will it spend too much time to development the test case before start to writing code? Because thinking all possibility cases is not easy.
concern: Hard to think of the tests User may not think of all test cases and miss a few.
concern: Hard to think of the tests Sometimes it becomes hard to think various test scenarios. Paired or mob thinking might be helpful in this case.
concern: Hard to think of the tests Coder must be ready with all the test-scenarios first. This may be difficult in real time situations.
concern: Hard to think of the tests My main concern for using TDD is ensuring that I write enough tests and the correct tests as I implement the feature(s).
concern: Hard to think of the tests initial "brainstorming" of the concept that needs implementation is fragmented when using tdd not going for the large overall use cases, this is iterative
concern: Hard to think of the tests Don't know where to start the tests and code dependency on hardware.
concern: Hard to think of the tests it may be difficult to come-up with tests without practice.
concern: Hard to think of the tests Initial time to adjust developing according to tdd will take some time
concern: Hard to think of the tests Convincing others to use it could be difficult.
concern: Hard to think of the tests It might be easy to miss some test cases initially. However, the demo shows an iterative approach (adding new tests as we see fit)
concern: Hard to think of the tests Thinking of tests to cover every possibility could become difficult with larger/complex systems.
concern: Hard to think of the tests I would be concerend that I wold be quick to jump to the larger tests before finishing off all the smaller ones. Especially checking that the buffer isn't full and empty at the same time.
concern: Hard to think of the tests It's hard to think what to test for and how to write them
concern: Hard to think of the tests Finding meaningful ways to break your code
concern: Hard to think of the tests How much testing is too much and how much testing is not enough. In some cases it is easy to determine what needs to be tested but in others it's difficult to determine edge cases.
concern: Hard to think of the tests It is hard with to think of tests and how to do it incrementally. Also, spending time with build errors.
concern: Hard to think of the tests The TDD refreshed me in what I have seen past FPGA teams do in verification testing. The hardest part for me is translating that to C++ C# but they languages were very easy to read & study.
concern: Hard to think of the tests I am still concerned on the approach of TTD. I understand the concept, but do not understand how/what steps to take to write Tests for our code...
concern: Hard to think of the tests Tests may be skewed when working by yourself. However, working in a team can provide the right direction.
concern: Hard to think of the tests It seems like you have to consider every little possibility and can get overwhelming.
concern: Hard to think of the tests I am worried I wouldn't know where to start when trying to create my own test functions.
concern: Hard to think of the tests As the program evolves, do we have to modify previous test code or do we have to still satisfy elementary test cases.
concern: Hard to think of the tests As the program evolves, do we have to modify previous test code or do we have to still satisfy elementary test cases.
concern: Hard to think of the tests I think it tends to be difficult to think of a test to make sure your code works as it should
concern: Hard to think of the tests How to decide on which tests are appropriate.
concern: Hard to think of the tests Avoiding redundant cases and balancing between bloating testcases and finding corner cases.
concern: Hard to think of the tests Its a tighter test/write loop than I'm used to.
concern: Hard to think of the tests Its slightly difficult
concern: Hard to think of the tests might become hard to work out what the next test is. How to know when you've written enough tests.
concern: Hard to think of the tests Might get confused what test i did already and what needs still to be done.
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.
concern: Hard to think of the tests It is hard not to jump into implementation and test one behaviour at a time.
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)
concern: Hard to think of the tests it takes a lot of time; its "new thinking"
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
concern: Hard to think of the tests It is difficult to make a step-by-step implementation (code/test).
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
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.
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.
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.
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.
concern: Hard to think of the tests I still have to change the way I think about writing code, perhaps the natural approach to coding does not lend itself easy to do TDD. I sometimes miss obvious (in hindsight) edge cases.
concern: Hard to think of the tests - Sometimes writing the tests take some time - Sometimes difficult to come up with edge cases for tests - Sometimes the test itself is wrong
concern: Hard to think of the tests memorizing the test cases are difficult
concern: Hard to think of the tests How to test functions that do not return a value and/or are not stateless is sometimes a headache.
concern: Hard to think of the tests It is not always simple to come up with the right way to test a module or to shoehorned yourself in a corner by getting ahead of the tests in the code
concern: Hard to think of the tests It is not always simple to come up with the right way to test a module or to shoehorned yourself in a corner by getting ahead of the tests in the code
concern: Hard to think of the tests I might miss an important test
concern: Hard to think of the tests At this point I don't have an overarching knowledge of the CppUTest directives, so I don't know how I could extend it.
concern: Hard to think of the tests I believe a lot of skill is required to define good tests with suitable coverage but no doubt that will come with practice.
concern: Hard to think of the tests Is also time consuming
concern: Hard to think of the tests if test code is not fully covers the problem the code is not fully functional!
concern: Hard to think of the tests Sometimes it maybe hard to think of scenarios that could occur.
concern: Hard to think of the tests Difficult to apply to a huge amount of source code where I just do tiny modifications.
concern: Hard to think of the tests Difficult to apply to a huge amount of source code where I just do tiny modifications.
concern: Hard to think of the tests Miss some important test or behavior of the system and think that it is working. Or think in the wrong way and have to redo all the tests and code again later.
concern: Hard to think of the tests Miss some important test or behavior of the system and think that it is working. Or think in the wrong way and have to redo all the tests and code again later.
concern: Hard to think of the tests Tests could be wrong
concern: Hard to think of the tests It is sometimes difficult to imagine the simplest solution.
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.
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.
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.
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
concern: Hard to think of the tests how it will works when the requirements changes dynamically ?
concern: Hard to think of the tests It would be challenging to implement in complex function which perform multiple tasks. There will be to many unknown scenarios.
concern: Hard to think of the tests What about existing code or piece of code, say posterior TDD? Aren't moving future bugs at the test code side? Worse aren't we adding maintenance effort on the test side?
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.
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
concern: Hard to think of the tests how not to over think or over design
concern: Hard to think of the tests if i hard-coded everything then forgot some test cases to check it
concern: Hard to think of the tests Thread safeness is hard ensure with TDD
concern: Hard to think of the tests I feel like its easy to get ahead of yourself and then have gaps in the testing.
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
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
concern: Hard to think of the tests Concerned I won't come up with tests to cover every case.
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.
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.
concern: Hard to think of the tests Should you write a test for everything?
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.
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?
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.
concern: Hard to think of the tests I'm concerned that I might miss things in the test-setup.
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.
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
concern: Hard to think of the tests It relies heavily on how well you write your tests
concern: Hard to think of the tests Writing tests could be difficult.
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
concern: Hard to think of the tests The number of tests needed could be difficult to estimate when sizing the effort.
concern: Hard to think of the tests Trying to think of every test case as the code is being written seems difficult
concern: Hard to think of the tests Sometimes it is difficult to write a test when the code does not yet exist.
concern: Hard to think of the tests Sometimes, it is hard to come up with the idea,of how to write the test
concern: Hard to think of the tests skills to write just enough code to pass test
concern: Hard to think of the tests i got the feeling, that finding the best "next test" to implement is one of or even the most important aspect in tdd.
concern: Hard to think of the tests A concern looking in from the outside perspective of development is that one may get lost in the weeds of this slower moving iterative process.
concern: Hard to think of the tests Although the test supports a solid design, the TDD requires a different mentality than I am used to.
concern: Hard to think of the tests I'm concerned about tests not being well developed and directing the implementation in the wrong direction.
concern: Hard to think of the tests Might test the wrong thing Are you adding tests that are useless/not doing anything? Hard to know sometimes
concern: Hard to think of the tests Its seems easy when you are fallowing test plan - its sure would be a lot harder without test plan.
concern: Hard to think of the tests I think it is hard to think of the tests and not get ahead of myself and write too much code. With practice, this should get easier.
concern: Hard to think of the tests It's hard to think of good, not redundant test.
concern: Hard to think of the tests It will be more difficult to write all the tests in the right order. Since the tests guide development, the order seems to matter a lot.
concern: Hard to think of the tests Practicing how to write tests that don't miss edge cases. The take it takes for me to know how to write each unit tests and quality tests in general (I assume Ill improve overtime).
concern: Hard to think of the tests By not writing the correct implementation to pass the test you might put yourself at a disadvantage later down the line.
concern: Hard to think of the tests It can be hard to write a test sometimes, and even harder to write a test that tests in the correct way.
concern: Hard to think of the tests What if I write a bad test and don't realize it right away? Will I waste more time trying to trying to debug issues caused by a bad test?
concern: Hard to think of the tests You have to be sure you cover any possible condition otherwise you would end up having the same bugs.
concern: Hard to think of the tests Discover the right tests to do
concern: Hard to think of the tests Applying it to code that depends on the hardware, dependencies to other modules, mking sure that the tests cover all requirements and use cases and boundary conditions
concern: Hard to think of the tests Applying it to code that depends on the hardware, dependencies to other modules, mking sure that the tests cover all requirements and use cases and boundary conditions
concern: Hard to think of the tests It seems not easy define the right test
concern: Hard to think of the tests There might still be lots of holes in my code
concern: Hard to think of the tests Shifting the thought process to think of test scenarios first
concern: Hard to think of the tests While you progress further in TDD and your previous tests fails, you tend to modify your code to make previous tests happy.
concern: Hard to think of the tests Difficulty in thinking about the tests needed for validation.
concern: Hard to think of the tests I am a bit concerned that it might take time to get the feel for this type coding. Maybe immersion and time is what it takes?
concern: Hard to think of the tests Getting stuck designing useful testcases.
concern: Hard to think of the tests It's important to implement your tests correctly, so you don't get a false sense of security
concern: Hard to think of the tests It's not easy to determine how much scope to break down for each iteration loop. In addition, it's hard to think of what tests to add in hindsight.
concern: Hard to think of the tests When to stop writing code How do I know I write the right tests
concern: Hard to think of the tests Nothing too concerning at the moment. It's all about getting the hang of having correct mindset to think in TDD way
concern: Hard to think of the tests Hard to slow down the development typical workflow. Tests are not always so obvious from the requirements. Legacy code may require extra concerns about undocumented details.
concern: Hard to think of the tests in the example I had tests already defined - that was fun, but I would need to change my way of thinking to first find scenarios, and then implement the code
concern: Hard to think of the tests You have to think the needed test.
concern: Hard to think of the tests I find it difficult to think, imagine and build TEST cases that not only serve to test the more immediate SW implementation I have just done, but also help me in future steps.
concern: Hard to think of the tests It is difficult to think well about tests. It is necessary to train the mind to think well in simple and concrete functional tests
concern: Hard to think of the tests I wrote bad code
concern: Hard to think of the tests i am so worried
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?
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.
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.
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.
concern: I have no concerns. Writing valid tests
concern: I have no concerns. No concerns yet
concern: I have no concerns. It "feels" like it take longer. However, trying to step back, in many cases I can see where this process would lead a faster development cycle. It also tests your test functions as you go.
concern: I have no concerns. No concerns so far
concern: I have no concerns. I have none
concern: I have no concerns. No concerns from me.
concern: I have no concerns. No concerns at the moment.
concern: I have no concerns. There weren't any concerns I had
concern: I have no concerns. No concerns
concern: I have no concerns. I don't have any concerns.
concern: I have no concerns. I was concerned on how much C/C++ knwoledge I would need for the training, but it's not a concern anymore
concern: I have no concerns. Think so far TDD is proving very useful.
concern: I have no concerns. Think so far TDD is proving very useful.
concern: I have no concerns. concern
concern: I have no concerns. lkjslkjkl as;lkasdlkj changed
concern: I have no concerns. Nothing.
concern: I'm Crazy How does TDD work with techniques like "Property Based Testing"? Can they be combined?
concern: implementation How to implement this in what we do at work.
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
concern: inadequate Implementing code to pass test may not guarantee it does what is supposed to if test coverage is inadequate.
concern: incomplete The many steps make it feel as if not all things are tested, especially the first few (very simple) tests...
concern: incorrect testing My test script for testing the code may be wrong and misleading
concern: infeasible Too structured and not that practical in a deadline driven work environment.
concern: Integration How can we integrate TDD with different Requirements?
concern: integration It is not yet obvious how TDD scales to integration or system level tests.
concern: integration code how to test integrated or system level code
concern: Interface Usually we lock down the interface so others can use it, this TDD approach keeps the interface in flux
concern: Irritating Allowing compiler/linker errors that you know are going to happen doesn't seem like it adds a lot of value.
concern: Laborious TDD has more deliverables since the functional code and the test code are required. This could appear as a hurdle to some.
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.
concern: legacy Integrating the concepts into our legacy codebase.
concern: legacy It seems very straight forward for new development but very hard to wedge into legacy code.
concern: legacy Can I apply TDD for the legacy codes when I change part of them?
concern: legacy How to make it work with legacy code.
concern: legacy Adding tests for new or existing functionality in code that was not at all written with TDD in mind.
concern: lengthy It feels like it takes too long. I instinctively want to write more.
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.
concern: limited identifying hard to track down integration or timing bugs that are not reproducible in a test-harness
concern: Limited-Time Spending some time to make TESTs.
concern: Linear I'd rather work on one function at at time, however TDD could be applied to this approach too.
concern: long process long repeated procedure breaks my flow of ideas on how the pieces are put together on the module I'm developing
concern: longer Results in additional work to revise previous tests when the interface/design changes midway through the TDD cycle
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.
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.
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.
concern: Mess? Sometimes I start making a test pass and suddenly more and more tests fail ...
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.
concern: More At first, it seems like a lot of extra code to write
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.
concern: More Code Lots of test code needs to be written
concern: more time Longer development time before first working proto release version.
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.
concern: new It goes against the grain of doing it the other way for many years
concern: None How to jump from the mockup environment to the real HW.
concern: None It can feel like a lot of friction to do something simple.
concern: none Nothing yet.
concern: None None.
concern: None none
concern: None making small changes that seems obvious makes you think you are going slower.
concern: None learning curve, takes a long time to become fast at TDD
concern: None Reuse of the tests in other tests
concern: None No concerns.
concern: None tests for complex products and UI components
concern: None Nothing!
concern: None I don't have any concerns as of now.
concern: None None, as if now
concern: None No concerns.
concern: None No concern
concern: None I don't have any concerns.
concern: None None
concern: None Not clear how much to test within each test. For example. Fill buffer. Empty buffer. Should we be testing IsFull and IsEmpty after each put and get?
concern: None Just seeing the test fail does not explictly tell us that what we are intending to test is failing. Possible false sense of security.
concern: None Some of the steps seemed very small and would waste time, but see that maybe this is more in the training to learn the system
concern: None Need to understand the test framework a little better for the helper functions.
concern: None No concerns so far
concern: None If a test case has any compilation errors, execution stops there itself. It is not going to the next test case.
concern: None Making tests
concern: None Writing tests for GUI might be more challenging.
concern: None Do not have any concern about TDD.
concern: None additional effort to write first test and than function, guess will need more time if we not just remove comments
concern: None A bit irritating in the beginning
concern: None nothing yet
concern: None Prograstination and lazy steps to get test pass has to be done in a smart way.
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.
concern: None Will it be as time efficient with bigger projects or when integrating older code?
concern: None How it will be applicated on our existing code that is more complex and already written
concern: None No concerns so far.
concern: None organizing the volume of produced tests
concern: None A lot of time is spend waiting for the compiler to discover that I forgot to define/declare a function.
concern: None Overhead of testing framework.
concern: None none
concern: None None
concern: None None
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
concern: None How can this work with hardware dependent code?
concern: None How can this work with hardware dependent code?
concern: None How can this work with hardware dependent code?
concern: None Nothing really
concern: None (Lack of) Acceptance by other embedded programmers.
concern: None Overlooking test cases. Accidentally leaving 'false positive' results in refactor.
concern: None I find it too easy to skip the "test fails" step
concern: None None so far.
concern: None Not many, I like it, just need to sharpen up on my C for your course. :)
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.
concern: None Nothing.
concern: None Hopefully covering all the test cases. Implementing the logic and knowing all the syntax for that.
concern: None Liking the method too much!
concern: None *The hardest part for me is sticking to the red, green, refactor cycle. I often skip the red.
concern: None I don't have concerns, it will take more time to code but it saves time in the end.
concern: None I don't have concerns, it will take more time to code but it saves time in the end.
concern: None Can be easy to get too far ahead
concern: None Initial Overhead
concern: None We don't teach it early enough in student's SW learning.
concern: None No concerns. It's tool I've used for 10 years.
concern: None nothing so far. but I've been wanting to take this course for a while so that's understandable.
concern: None None at all because I was already familiar with it
concern: None how to apply to Python and PHP
concern: None None
concern: None nothing
concern: None no concern, all fine (:
concern: NoRequirements Where are the requirements
concern: normal It takes me a lot time to develop task with TDD. But I will try it.
concern: not Somebody will think that is a method to fit all use-cases.
concern: Not covering all I sometimes felt afraid there were needed test cases we would miss, not covering all expected behaviour.
concern: not enough time I don't have enough time to develop full test case on my real work.
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?
concern: nothing nothing.. i think it works fine
concern: obstacle dependencies and coupling
concern: old habits risk falling in to old habits of not using when stressed
concern: Other. Adding hard-coded values to pass specific tests. Could forget that and leave it to the source code
concern: Other. Procrastinating. It feel so natural that it must be wrong somehow.. Sometimes it may be difficult to spot the shortcuts later on
concern: Other. My main concern is that unit testing (not TDD) only can make you focus too much on the details and miss the big picture. You risk making wrong design choices and then be heavily invested
concern: Other. What TDD will be like in more complex implementations, with lots of dependencies.
concern: Other. I could miss some functions with hardcoded return values or some cases without being properly tested.
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.
concern: Other. You might forget of some harcoded value that you wrote just to make a test pass that interfiers know with another test
concern: Other. Writing code that I know is not going to work, just to pass the test.
concern: Other. Hard to think in small incremental steps
concern: Other. Will this approach work on embedded code, with hw dependencies, and on more complex problems ?
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?
concern: Other. Though I understand the reason behind it, it felt wrong to hard-code things when I know what should actually be implemented.
concern: Other. Trying to compile a test that doesn't have supporting code will slow cycle time and will confound scope-aware IDEs.
concern: Other. It adds a layer of complexity that requires some understanding and skill to tackle.
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.
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.
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
concern: Other. What's the test completion criteria? How to identify test gaps?
concern: Other. Changing a prototype could lead to lots of broken tests. Finding the right amount of up-front thinking about your interface. But this is likely something that comes with experience.
concern: Other. overhead of test
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.
concern: Other. inaccurate test results due to hardcoded values
concern: Other. I'm a little concerned that the process may force multiple refactors since the early tests may allow a simple implementation.
concern: Other. It does seem that TDD can lead to some work arounds or repetition if you do not go back and fix earlier revisions.
concern: Other. It seems easy to fool oneself about whether test coverage is complete or not. It's easy to overlook some edge case, have all tests pass, and believe one's code is thoroughly tested.
concern: Other. It seems easy to fool oneself about whether test coverage is complete or not. It's easy to overlook some edge case, have all tests pass, and believe one's code is thoroughly tested.
concern: Other. I'm not a big fan of hard coding returns just for the sake of passing tests. I understand that it's a part of the process but it's counter to what I've learned previously.
concern: Other. Setting up the tools in actual project code.
concern: Other. Hard to think in such small increments
concern: Other. Hard to think in such small increments
concern: Other. can forget to change fake results to real results
concern: Other. can this be thought of as independent testing? But I like the idea of the devs providing the SQA, in pair work one reviews the work of the other
concern: Other. can this be thought of as independent testing? But I like the idea of the devs providing the SQA, in pair work one reviews the work of the other
concern: Other. It can be frustrating that you know what is and will be needed but not implement it right away. But I guess that's the whole point, because when you think you know implementing right away things break
concern: Other. I guess that the this approach should be shared and agreed by all the developers in the team.
concern: Other. my concern
concern: Other. that it might not be so easy to use in more realistic (and complex) scenarios
concern: Other. May not be clear order of tests to write. Probably would think of tests to write simultaneously while thinking of interface.
concern: Other. I'm concerned that I think ahead and jump to implementation. I need to slow down to think about testing
concern: Other. How do you avoid overly brittle tests that are far too sensitive to internal changes?
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.
concern: Other. Not feasible to compile after every test if build process takes too much time
concern: Other. Sometimes we need to modify the code just to maintain the old tests
concern: Other. I need to keep a separate list of tests to implement as I think of them. It would be nice to just put the test down as I think of it even though it's not ready for prime time.
concern: Other. TDD could create excess code.
concern: Other. TDD could create excess code.
concern: Other. TDD could create excess code.
concern: Other. TDD could create excess code.
concern: Other. I'm concerned that I won't be able to convince my team and managers that this is a worthwhile practice.
concern: Other. use it in real world
concern: Other. Being able to structure the development process when we don't have a structure - like the one in the exercise - outlined for us.
concern: Other. There is a lot of outside-class material/time to spend. The volume of material, and different ways of interacting with the site is a little chaotic, and distracts from the learning, or listening.
concern: Other. Implementing code differently than you plan to at the start just to get the test to pass is counterintuitive.
concern: Other. the most important things seem: the test must be properly written. in this case you gave us already the title of the tests, which HAS to pass in order to have a fine working buffer
concern: Other. When jumping ahead a bit too much, I was a tad miffed trying to figure out what to comment out.
concern: Other. It's definitely a change from my current coding paradigm.
concern: Other. The primary goal being test of the code and not the application.
concern: Other. Using TDD within a developed system and how it will merge in with untested code.
concern: Other. Intentionally implementing bugs instead of doing it right the first time
concern: Other. I didn't like how it was penalized to think ahead
concern: Other. It was difficult to adjust mentally to coding to pass tests first without solving the whole problem (i.e. hard coding values)
concern: Other. There will be alot of tests but not a bad thing
concern: Other. I wish there were more guidance on how to perform TDD in the discussion notes in the exercises.
concern: Other. Does one strictly adhere to Fake-it-till-you-make-it? For example, we have implemented the circular buffer before we tested for this specific behavior and this was flagged in the output result.
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
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)
concern: Other. Gives me anxiety when you can see the future problems at the earlier steps and you can't code ahead
concern: Other. It remains to be seen how this can be applied to our legacy code base
concern: Other. Applying this to neato's codebase because of tight coupling / dependencies
concern: Other. How does this scale up to higher order tests - perhaps functional or whole system?
concern: Other. It requires discipline which I lack.
concern: Other. Writing code that I know is wrong. It feels counterproductive.
concern: Other. some of the fake implementation may get left in production code
concern: Other. it is more difficult to use for code that requires interaction with hardware
concern: Other. TDD is about Development not Design. It doesn't necessarily lead to the best designed software.
concern: Other. TDD is about Development not Design. It doesn't necessarily lead to the best designed software.
concern: Other. How do I maintain this Minimal Increment approach, when deep change is required -- eg. CircularBuffer wraparound and fullness.
concern: Other. can lead to an over simplified implementation that takes more refactoring later when more complex tests require a full implementation
concern: Other. can lead to an over simplified implementation that takes more refactoring later when more complex tests require a full implementation
concern: Other. If you want to make breaking changes to make a test pass, should you comment out the test and refactor? or make the change and fix the old broken tests one by one?
concern: Other. It is possible to pass all the tests, while still missing key functionality. It is not a replacement for other methods of testing and review.
concern: Other. Hardware-in-the-loop testing may be interesting
concern: Other. Hardware-in-the-loop testing may be interesting
concern: Other. I feel somewhat separated from building a robust mental model of the algorithm -- and I like to end up understanding my algorithms so thoroughly that I can mentally prove their correctness in my head.
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!
concern: Other. If the project grows, the compile time might get too long. What about third party dependencies? How to deal with them?
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.
concern: Other. No worries at the moment
concern: Other. Nothing to complain
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 ?
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.
concern: Other. It's difficult to hold back wiring the whole implementation while doing TDD.
concern: Other. Having to focus on designing the test first and then only keeping myself to write code that satisfies the test, and not code features that "I might need later" or "early optimizations".
concern: Other. My only concern is that it is hard to break old habits and even during TDD, I tend to cut some corners here and there. It takes time and some effort to overcome that.
concern: Other. my concern is when the tests miss something
concern: Other. In CyberDojo, unless I feel really confident, I am coding perfectly, I need to opportunity to debug, and I can't provide myself output.
concern: Other. Is it possible to miss the 'big picture' by just making the it pass the tests... No, I don't think so, IF your tests are accurate/representative.
concern: Other. I'm concerned that the TDD approach may not scale well or apply to most real development efforts.
concern: Other. In my embedded system firmware I configured an input capture peripheral for measuring the frequency of a signal. Can I test that the peripheral is configured truly and that captured values are true?
concern: Other. The test results give a summary of the number of tests run, etc. Is there a way to create a report of the tests themselves, along with a pass/fail status?
concern: Other. Good for new software, but not so good for changing existing software (not yet covered by tests)
concern: Other. - sometime misunderstanding test result (example what yellow sign really mean)
concern: Other. Good for new software but I'm wondering how it will work for code already existing and without tests yet.
concern: Other. Testing code which calls other code might be expensive (time, environment)
concern: Other. who do I reach the end of the test code? when I is finished? who decides this?
concern: Other. It's still the developer who implemets the testcases from his coding point of view and might oversee important states which an independant tester won't.
concern: Other. the fact that code can be written to pass a test but might not be functional.
concern: Other. Sometimes it is harder to make it fail first, when the solution seems obvious. Making it fail first in some cases, not all, forces situation that may never occur
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.
concern: Other. Will changing the code affect the test code? For example changing the function signature.
concern: Other. Should try to cover as much scenario as possible to not miss any feature.
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.
concern: Other. hey 1023
concern: Other. It really requires self dicipline to write those minimal, not-functional-but-make-green-test implementations.
concern: Other. Some types of requirements may be difficult to verify this way, particularly multi-threading issues with lots of asynchronous randomness.
concern: Other. My concern is that the test code now has to be maintained as well.
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.
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
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.
concern: Other. So far we have used cyber-dojo. How do I integrate CppUTest or another tool to a current project?
concern: Other. That certain parts of embedded development would have a hard time utilizing TDD
concern: Other. Strict TDD emphasizes one step at a time when experienced programmers may be able to at least combine one or two steps.
concern: Other. lose confidence when something is "done"
concern: Other. It's hard to not want to get ahead of yourself during implementation
concern: Other. When I don't know how to test something, e.g. dynamic memory allocation.
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...
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...
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.
concern: Other. Hard-coding the implementation to make the tests pass feels morally wrong (this eventually wears off?)
concern: Other. my concer is that I look stupid
concern: Other. When I am doing it allone, it's sometimes hard to come up with a decision.
concern: Other. Spending too much time in the incremental code construction that I might forget some hard-coded values later on.
concern: Other. Integration of unit-testing sw with current toolchains...
concern: Other. I don't fully understand how to utilize the create/setup functions yet to ensure I'm testing the proper things.
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.
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
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.
concern: Other. some of the error messages are not that easy to decode (I am sure this will come with practice though)
concern: Other. Development process is backwards compared to how most developers are trained. May make it harder to get adopted in a team
concern: Other. I feel like there is high potential to miss steps if you keep putting off implementation details until later on.
concern: Other. Colleagues not doing it in common code
concern: Other. It seems not possible that one guy writes a test and the other guy writes the implementation unless we would work in a close pair programming.
concern: Other. we pair, actually we mob, and I'm wondering styles/options for TDD together, rather than solo.
concern: Other. Refactoring seems like it can be a nightmare with 30-40 tests intermittently failing as you continue (sometimes due to a fundamental issue).
concern: Other. Learning the framework, though that's only a concern at this point, when I haven't used it too much.
concern: Other. I am concerned about adding a layer of complexity to my programming. I expect this to resolve with more experience with TDD.
concern: Other. Getting whole team to do it. Takes humility and extra skills.
concern: Other. Writing a test and then writing just enough code so that it passes becomes frustrating when you can already figure out how the final implementation is going to be
concern: Other. It can be tricky deciding between the simplest thing to make a test to pass versus picking something a bit more complicated that moves us towards the goal.
concern: Other. It maybe be that there is more setup time involved with unit testing, and getting old code under test may be tough.
concern: Other. I see the benefit to the warning about developing code ahead of test, but in 1.C I found myself repeatedly commenting out and then adding back my full and empty checks in put and get functions.
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.
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.
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.
concern: Overthinking I notice my mind tries to go 3 steps ahead instead of sticking to the step-program. Hard to shutdown/slowdown
concern: Overview After a while I am doubting whether my original tests still provide the "correct" coverage /mindgames?
concern: Overview The sheer endless amount of tests you write may clutter the overview of what is tested, and what not (yet).
concern: overwhelmed I wish we started with a much simpler code.
concern: overwrought - Writing templated wrong code to end up rewriting right code. - the design follows the test
concern: pass Making test code to only pass.
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
concern: Portability Portability.
concern: Practice Might take some time getting better at the process at the beginning.
concern: Practice Takes time to get familiar with.
concern: practice Can I make every test codes when I write codes in the real work?
concern: practiciality It's not suitable for things which are highly difficult to test e.g. UI code
concern: predecessor Implementing it against an already established code base
concern: procrastination Getting the experience to figure out when to drive toward a solution or delaying implementation.
concern: progress-ish? it can feel like you are making good progress when you are may actually not be developing much useful functionality.
concern: puzzled Integrating with components that I control. Integrating with components that are 3rd-party controlled. Integrating with system components.
concern: range how much test range is similarity with real testing
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
concern: redundant Total running time of test suite might become to large because of a lot of redundant tests.
concern: refactor time In a large system, does it take much effort to refactor code for every new test case?
concern: retrofitting Retrofitting legacy code seems like it would be overwhelming.
concern: rework risk of not planning enough by just designing for the next test, requiring a lot of rework
concern: rework Am I wasting effort refactoring code that I *KNOW* is wrong in the long run (like with hardcoded values)?
concern: Scalability Concerns about scaling to more complex functionality and hardware integration.
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?
concern: schedule how to add this type of testing without impacting overall schedule
concern: Scope Developer writing test cases for own code? How much time to devote for writing tests?
concern: Security False sense of security, "All my tests pass so I must be alright!" But in reality the tests were just written poorly.
concern: self-limiting It's really hard to limit myself to the smallest possible change.
concern: Short-cuts Easy to short cut the steps by knowing where you want to get to and doing many steps at once.
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?
concern: situations I am not sure if we tested everything there is to test up to now
concern: slow It will slow me down when coding. Not used to writing test before implementation.
concern: Slow Very time consuming. Baby steps not often appropriate for fast development cycles. Antagonistic to requirements driven development as dictated by many outfits.
concern: slow Feels slow when I think I already know the implementation required.
concern: Slow Slows down development time
concern: slow 1. Development becomes slower 2. When I start with new tests, I may need to rewrite/refactor existing code.
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.
concern: Slow process Slows down development process.
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?
concern: Speed A fast build system is critical.
concern: Stranger I make me stranger things. Because It's news for me. Do we need it when my system's small?
concern: Strong How to test all function with simple, cover all condition
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.
concern: Subjective Just because there are tests, it doesn't mean they are good tests.
concern: syntax New keywords/test syntax to learn. Need cheatsheet/quick reference to help make development of tests efficient
concern: taking time It takes more time to develop features
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.
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
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
concern: Test bugs We can write bugs in the test cases.
concern: test case Sometimes I faced the limit of my imagination, how can I specify test cases which is fully testable my module?
concern: test for corner case I concerns about how to make test code for corner case.
concern: Test Mistakes Writing bad tests which give you a false sense of security.
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?
concern: testcase How do you systematically write test cases?
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
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.
concern: There is no design. Is there a way to make sure that enough attention is paid on high level design as well, TDD seems to work on smaller details.
concern: There is no design. Sort of straightforward with well defined problem when specification is clear. How about situations when these are not fullfilled?
concern: There is no design. Think before coding
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.
concern: There is no design. TDD creates code in a very small incremental way.. but does this generate code that is efficient, fast and optimized, or do we get drawn into a sub-optimal implementation?
concern: There is no design. I don't like to implement things wrong
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.
concern: There is no design. I could "overfit" and "cheat" and make tests pass even if my implementation is a hack
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
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.
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.
concern: There is no design. If a test case is missing, we will miss the code for a use case.
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.
concern: There is no design. TDD is not separating requirement from implementation testing.
concern: There is no design. Not sure how it fits into a large system approach (not a simple, well-defined class). How does the bigger picture work?
concern: There is no design. Writing lots of code that I know is wrong / incomplete. Changes in interface is painful. Easy to put off hard problems that may drive lots of busy-work.
concern: There is no design. Break initial cases when change the design later?
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).
concern: There is no design. Setup and Tear down might work for simple tests.What if we need to test more complex scenarios? Would we need to use helper functions to get to a state?
concern: There is no design. With the 'faking' it seems that there is no pre-mediated design efforts and that design happens as a side effect of the testing. this seems backwards.
concern: There is no design. Is TDD scalable?
concern: There is no design. One concern it helps to have a strong idea of the interface/features before you begin, otherwise more time is spent on refactoring code to meet introduced functionality.
concern: There is no design. TDD should not replace design.
concern: There is no design. Developing code this way will force you into a local min of a on optimal. No opportunity for arch that is expandable b/c ur code is a product of behavior rather than behavior be a product of good arch
concern: There is no design. None to think of
concern: There is no design. Is it possible that this method does not allow flexibility for code changes down the road? Feels like if the design specifications change it might leave us with a structure that is harder to change.
concern: There is no design. Thinking in terms of TDD and thinking in terms of internal software design are somewhat at odds or in potential conflict or at least competition with each other.
concern: There is no design. When there is no initial design code or you are unaware of what you need to create, TDD can be difficult to start
concern: There is no design. Implementing the bare minimum to pass each test can lead to large code changes later that may have been easier to implement if done from the beginning.
concern: There is no design. Without design or architecture up front, how do we keep the design from going totally off the rails?
concern: There is no design. More of an exercise comment than a TDD comment, but I prefer push_front/push_back/pop_front/pop_back names to put/get.
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 ;)
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
concern: There is no design. Both implementation and test are undocumented.
concern: There is no design. for the demo, not scoping worst case of circular buffer with memory constrained devices, dynamically allocating memory concerns me.
concern: There is no design. Sometimes I try to think of the problem holistically when designing software. But it seems to me that the "fake it until you make it" approach, prevents this.
concern: There is no design. It isn't clear what order to start implementing the various parts.
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--)
concern: There is no design. It is hard to write tests if you do not know what to implement.
concern: There is no design. There seems to be no notion of "design" - where we are approaching it with one bit at a time. Some times we are applying an existing "design pattern" or approach. What to do in such a case?
concern: There is no design. Lack of scope as the function unrolls; potential for necessary re-do of functions
concern: There is no design. Fit this simple problem well - will it fit more complex problems requiring more complex design decisions?
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."
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
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).
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.
concern: There is no design. The design may just grow, without being related to a higher level architecture.
concern: There is no design. In the circular buffer example we have a design, but in some actual practice we jumped directly into some test and writing code without a high level design.
concern: There is no design. switching too often between test and development context. (e.g: for implementing algorithms may not work)
concern: There is no design. It was not always intuitive to develop tests and know when to run to failure. It felt messy passing on hardcoded values and it is difficult to know what done is if we are writing our own tests.
concern: There is no design. Possibly not fully thinking about entire implementation.
concern: There is no design. Possibly not fully thinking about entire implementation.
concern: There is no design. It is time consuming.
concern: There is no design. It is time consuming.
concern: Think Tfind It's fit the way that we work.
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.
concern: time Not implementing it in the correct way. I.E. with a 'develop, test, TDD' mindset will simply produce more work.
concern: time Is it save time to develop and maintain system ?
concern: time hard to categorize the test case time consuming
concern: TIME I think TDD will take long time to develope software. How about big project? Can TDD be applied without project size?
concern: time Painful. A lot slower than normal development. A price for the benefits but still something I don't like.
concern: Time It takes long time when new to it because it is another way of thinking than you are used to.
concern: Time Time to get code written. BUT.... that is partly inexperience, and you get the benefit of code security
concern: time consuming Full-blown TDD seems inefficient and overly time consuming.
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)
concern: time consuming It feels time consuming without building momentum.
concern: Time Consuming Requires good unit testing skills to create more scenarios as this becomes essential for TDD
concern: time consuming time consuming need to write code with knowing that it will be scrapped later
concern: Time Consuming It slows down development and may affects the deliverable
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...
concern: Tiny steps Small steps sometimes hard to reconcile with big picture.
concern: ToAddAllTheTests When writing the tests, not to miss come test condition.
concern: too early Just started learning it so I feel too early to raise any concern
concern: too much code Test code is too much. For example, if source code is 5 lines, test code will be 20~25 lines.
concern: Too much test code. For simple problems it requires more time to think and write the tests, than to write the solution.
concern: Too much test code. The concept of more test code than production code, implies more code to maintain
concern: Too much test code. Difficult to make interface changes without having to change the tests
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.
concern: Too much test code. How much tests is it viable to write during startup of a project? Things might change.
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.
concern: Too much test code. How quick can this approach be adopted by a team.
concern: Too much test code. i might end up overengineering the testcases
concern: Too much test code. Like to know more details about how to use TDD to project development, and how to improve the code quality, and how to balance the test cost and development cost.
concern: Too much test code. Like to know more details about how to use TDD to project development, and how to improve the code quality, and how to balance the test cost and development cost.
concern: Too much test code. you now need to have confidence in your tests and our design... twice as much code
concern: Too much test code. Probably too many test cases. I would personally fit some of them into a single test.
concern: Too much test code. Our implementation differed from the suggested one. It passed, but it may not be bug-free. It could go wrong when int overflows. Even, with the test the code may get wrong.
concern: Too much test code. it may take lots time and lots test codes.
concern: Too much test code. How many test case is enough or good
concern: Too much test code. Our focus may move more towards the test cases writing. (May be doing first time so I have this feeling)
concern: Too much test code. Too much test code
concern: Too much test code. Lots of test code to be written to test each and every scenario of code.
concern: Too much test code. Looks like it will take more time on the test code than the actual code.
concern: Too much test code. Too much test code
concern: Too much test code. I can imagine there being a lot of tests. Maybe it's a good thing, but I can see it being a nightmare to fix tests if we have to change implementation.
concern: Too much test code. Large amounts of test code being stored, could be hard to manage in larger systems.
concern: Too much test code. Not to fall into a trap of writing tests for the sake of it, rather than writing good tests.
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 :/
concern: Too much test code. You get caught up into testing too many things which are maybe not necessary
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.
concern: Too much test code. Verry small steps tend to lead to testing of implementation. This makes changes harder. Slowing my self down by taking too little steps
concern: Too much test code. Sometimes slow in synchronizing code changes to other team member.
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
concern: Too much test code. There is maybe quite a bit of test code that could be hard to maintain
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.
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.
concern: Too much test code. I'm concerned that tests written during TDD will have some overlap with acceptance tests. Test duplication...
concern: Too much test code. Forging ahead and not taking time to remove duplication
concern: Too much test code. We would spend more time writing test code.
concern: Too much test code. Lots of tests could be hard to maintain.
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
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.
concern: Too much test code. How do I fit all this test code into my embedded development?
concern: Too much test code. It can lead to bloated code security holes may be introduced
concern: Too much test code. More test code than actual code.
concern: Too much test code. That it will be a challange to start using TDD in every day coding
concern: Too much test code. That it will be a challange to start using TDD in every day coding
concern: Too much test code. In general we have a lot of code and it is quite coupled
concern: Too much time. I will need some proof that the total development/debug time is actually shorter when using TDD.
concern: Too much time. After one has established routines, the flow will probably not not be as disciplined, and bug potential rises.
concern: Too much time. 1. I think time is a valuable resource in company that not exists much of, it takes time... But on the other hand, we save a lot of time in the future if we do things right from the start...
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
concern: Too much time. Waste of code
concern: Too much time. The structured approach can take some time for basic tests.
concern: Too much time. Using a debugger to develop the code would be faster. Tests could be written after.
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.
concern: Too much time. Extra development time
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.
concern: Too much time. It takes longer than coding and then testing. We keep rewriting the same code over and over.
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)
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.
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.
concern: Too much time. At times it feels tedious and slow.
concern: Too much time. I have a perception that it takes longer to develop something even though it might save me time in the long run.
concern: Too much time. TDD has clear value, but I'm cynical. Several managers from my career would view TDD as optional, wasting time. "Why test, just do it right." This is not an issue with TDD, rather the industry.
concern: Too much time. It takes longer than the quick and dirty solution.
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.
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.
concern: Too much time. overall time spent debugging test code
concern: Too much time. it seems difficult to fully accept the philosophy and to know when it's time to stop writing code (the minimal impl to pass tests). the process seems having an overhead over the time spent development
concern: Too much time. Maybe there is too overhead, since every time I want to add a new functionality to my code I have to fail, modify, fail again and so on
concern: Too much time. Its bit slow approach . And more re work is needed if we keep adding complex test cases for later stage.
concern: Too much time. Seems to work better with a fast compilation cycle. Ours isn't. :(
concern: Too much time. It require more time at beggining
concern: Too much time. Jumping between compiler/linker errors (which are mostly obvious) is a waste of time.
concern: Too much time. It might be more time consuming than directly implementing it. If something is obvious, do we need to make a test fail first then implement it?
concern: Too much time. -Need a paradigm shift in the way we approach development -Not sure we will implement it despite it's advantages -Legacy code?
concern: Too much time. takes more time to delivery
concern: Too much time. takes more time to delivery
concern: Too much time. takes more time to delivery
concern: Too much time. takes more time to delivery
concern: Too much time. takes more time to delivery
concern: Too much time. Feel like it takes much time
concern: Too much time. It is slow at times, feel like there are some unnecessary steps in there.
concern: Too much time. Deadlines
concern: Too much time. It seems like it will slow down development.
concern: Too much time. longg
concern: Too much time. It seems like it takes forever to complete a simple task. Very concerned about faking things for tests.
concern: Too much time. It takes a lot of time to incrementally write functions.
concern: Too much time. I know module 1 was an extreme example but I didn't like having to 'trick' my code into passing one test just to go back and fix it later. I'm concerned about the time investment for mocks/fakes.
concern: Too much time. For large projects, the amount of time spent testing every functionality could be incredibly large, given the last exercise was just for a FIFO.
concern: Too much time. Taking too much time fighting code errors on just the skeletal structure. However with time this should become easier =due to the templates created from previous projects.
concern: Too much time. Taking too much time fighting code errors on just the skeletal structure. However with time this should become easier =due to the templates created from previous projects.
concern: Too much time. Taking too much time fighting code errors on just the skeletal structure. However with time this should become easier =due to the templates created from previous projects.
concern: Too much time. Sometime you’ll get the sensation that you simply need an extended duration of your time for straightforward implementations
concern: Too much time. Making the test fail first seems slow.
concern: Too much time. That I would get too caught up in passing a test that I've written incorrectly before realizing the test is wrong
concern: Too much time. time consuming and overall end2 end functionality
concern: Too much time. developement cycle takes much more time and depending on the complexity of the code / tests this is exponential
concern: Too much time. The overhead of context switching between developing business logic and this scaffolding activity of testing
concern: Too much time. The added time it may take initially (even if it saves you time on the back end)
concern: Too much time. It would be difficult to implement in a complex code base that has already been developed
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.
concern: Too much time. The process seems to require re-writing code, which could be time consuming
concern: Too much time. It new to me and takes longer
concern: Too much time. test concern
concern: Too much time. test from lounge on concerns page
concern: Too much time. hey, 2:57 fri
concern: Too much time. It takes too long and makes me feel like a code monkey.
concern: Too much time. it's almost midnight
concern: Too much time. Initially I took sometime to understand what am I going to do during the TDD.
concern: Too much time. The tempo of TDD is slow, is it suitable for fast-pace development?
concern: Too much time. The tempo of TDD is slow, is it suitable for fast-pace development?
concern: Too much time. It will spend more time to develop the test code.
concern: Too much time. The exercise takes too long.
concern: Too much time. None
concern: Too much time. None
concern: Too much time. We might bypass the original motive while concentrating on granular stuff or while writing the tests
concern: Too much time. Time required for complex problem.
concern: Too much time. development timing may increase
concern: Too much time. Switching between test case mindset and developer mindset.
concern: Too much time. The micro steps of 'faking' seem to create extra work.
concern: Too much time. Going through the motions of watching the test fail to build, then build but fail, and then finally pass can feel tedious when a test case is trivial.
concern: Too much time. The only concern that I have is with respect to the extra time it takes to develop the tests.
concern: Too much time. Adds lots of overhead to writing code.
concern: Too much time. I think design is taking a back seat
concern: Too much time. It seems time-consuming for simple functions. Too much planning ahead.
concern: Too much time. It is much slower to develop code (at least if you only go one small step at a time). Might be faster to code out dummy tests and implementations of API functions all at once
concern: Too much time. Hope we will have the time to use TDD.
concern: Too much time. Making an adjustment to a small piece of code might upset many tests.
concern: Too much time. test concern
concern: Too much time. It is such a particular process that I have a tendency to jump ahead because the best practice seems silly and unnecessary at times. Might lead to more work.
concern: Too much time. It's a slow process.
concern: Too much time. It is such a particular process that I have a tendency to jump ahead because the best practice seems silly and unnecessary at times. Might lead to more work.
concern: Too much time. It is such a particular process that I have a tendency to jump ahead because the best practice seems silly and unnecessary at times. Might lead to more work.
concern: Too much time. My biggest concern at the moment is whether the efficiency outweighs the time consumption to TDD. It almost seems like you're testing twice by using this method but I'm keeping an open-mind.
concern: Too much time. TDD works best when implementation is known beforehand. In problems where the solution depends on experimentation, TDD slows down the process because tests have to be rewritten.
concern: Too much time. It was hard to collaborate when only one person can test the code at a time
concern: Too much time. I am not used to write C++ in the past 25 years
concern: Too much time. Seems like a slow process.
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.
concern: Too much time. I did not like having to wait ~5 seconds every time I ran the tests
concern: Too much time. Might be time-consuming initially.
concern: Too much time. May take very long to complete the overall task assigned.
concern: Too much time. it feels a bit slow - for simple problems I would code more interface APIs and tests in one go.
concern: Too much time. Opposition to this approach from project management. Hard to sell as it may be perceived that extra spent is spent doing log of iterations.
concern: Too much time. Hard to sell to management as they will argue oh it is too many iterations which will take more time and more budget
concern: Too much time. Hard to sell to management as they will argue oh it is too many iterations which will take more time and more budget
concern: Too much time. It is slow, and you must restrict your solution just to fix the test. I feel like slow
concern: Too much time. Filling in dummy/hard-wired values and then replacing them didn't actually seem to make reasoning about the tests any easier, and just slowed down later coding.
concern: Too much time. Takes too much time, too slowly, to write incremental tests and refactor for straight forward obvious concepts.
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.
concern: Too much time. It's longer than usual, but I think it worth it !
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?
concern: Too much time. something
concern: Too much time. Based on the timeline it may take too much time upfront.
concern: Too much time. Implementing the tests might be more work than the implementation it self.
concern: Too much time. Slows down the development of "easy" tasks
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.
concern: Too much time. Is it really going to be faster overall?
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.
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.
concern: Too much time. It feels very slow. I feel like I could get everything implemented faster if I think about and then implement everything all at once.
concern: Too much time. Much time taking.
concern: Too much time. Takes a long time, can be tedious
concern: Too much time. The effort for all these tests...
concern: Too much time. TTD is very time consuming, but it will help to avoid problems at the beginning
concern: Too much time. seems to need more time for coding
concern: Too much time. Will it be as time efficient with bigger projects or when integrating older code?
concern: Too much time. Unclear how to apply this '1 line of code at a time' and watch it fail- knowing it'll fail. Also there is we a lot of build time involved in how we build our code.
concern: Too much time. This can be very time consuming if the code will not be re used
concern: Too much time. It is not the most fun way to write code.
concern: Too much time. Time commitment and adapting to changing requirements
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
concern: Too much time. test 1
concern: Too much time. test 2
concern: Too much time. test 3
concern: Too much time. test 4
concern: Too much time. test 5
concern: Too much time. fjsdfljhsdflijsh
concern: Too much time. The speed (slow), or the perceived speed to get to a working FW.
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.
concern: Too much time. way too slow
concern: Too much time. way too slow
concern: Too much time. More time for development
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.
concern: Too much time. Slow built times == frequent interruptions when trying to get into a "flow".
concern: Too much time. it could be simulated env but it's slow
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.
concern: Too much time. Integrating to a old project with a lot of dependecies.
concern: Too much time. I am concerned that taking the time to do each of the TDD steps will take up too much time.
concern: Too much time. I am concerned that taking the time to do each of the TDD steps will take up too much time.
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.
concern: Too much time. A LOT of iteration.
concern: Too much time. A LOT of iteration.
concern: Too much time. Getting to the first passing test for a new embedded target can be time-consuming.
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.
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
concern: Too much time. Too much time to continue writing test cases before writing applicable code.
concern: Too much time. Is looks like time consuming effort to test over and over the code that is not yet finished.
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.
concern: Too much time. Scheduling time for setting up tests.
concern: Too much time. The iterative process seems very time consuming
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.
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.
concern: Too much time. It seems that later tests can cause your previous tests to fail taking up time to restest
concern: Too much time. Development time could increase on the front end and there's the risk of developers writing subpar code that simply passes tests.
concern: Too much time. too many small steps
concern: Too much time. progress per (test-)iteration is quite small
concern: Too much time. It seems that in the beginning the process starts too slow.
concern: Too much time. It requires discipline and humility. May appear slow to some people and hence skipped.
concern: Too much time. It seems very time consuming to have to refactor each function so many times, when you already have the initial requirements.
concern: Too much time. Time intensive, learning curve, requires spending time on something other than simply writing the required code.
concern: Too much time. - Not sure if it's too incremental? Initial implementation takes longer b/c of the constant refactoring
concern: Too much time. - Not sure if it's too incremental? Initial implementation takes longer b/c of the constant refactoring
concern: Too much time. Concerned it might be hard to do this efficiently when adding the time to come up with the tests as well.
concern: Too much time. Concerned it might be hard to do this efficiently when adding the time to come up with the tests as well.
concern: Too much time. It often feels slow.
concern: Too much time. I fear it could lead to issues only focusing on getting the test to pass
concern: Too much time. Large amount of time spent.
concern: Too much time. I'm concerned about the time it takes, although the response back if something is broken in code is great.
concern: Too much time. Is it always necessary? If not, when is it necessary?
concern: Too much time. Slowness at the moment but I can accept compared to the results
concern: Too much time. It can get frustrating. Doing everything step by step.
concern: Too much time. It is frustrating early on to have to write simple tests and do the minimum for them to pass early on when you can easily think ahead to a more working implementation.
concern: Too much time. - different approach to a problem - need to get used to it
concern: Too much time. The amount of time it takes to write any meaningful code is far greater than it would be without TDD.
concern: Too much time. Doing it iteratively seems like it will take a lot more time than just implementing the code and testing it afterwards.
concern: Too much time. I don't have any concerns so far. This platform is really amazing and looking forward to learning a lot from this workshop. But I feel it is taking a lot of time to complete the unit tests.
concern: Too much time. It feels like it takes longer, but I think it's worth it.
concern: Too much time. I'm concerned that it can slow you down. Especially in environments without incremental build capabilities.
concern: Too much time. The initial time investment required to write tests can slow down the development process at the beginning. There is a risk of writing too many tests.
concern: Too much time. I see how TDD can speed up total dev time, but I've had bosses in the past who absolutely would see testing this early as delaying implementation.
concern: Too much time. The time concern is my only one at the moment. I feel as I gain experience with it though the time to tdd will decrease.
concern: Too much time. My biggest concern is people's tendency to comment out tests and stop writing them when a deadline draws near, often with pressure to do so from management.
concern: Too much time. fake-it-till-you-make-it and thinking about tests first seems to take some time
concern: Too much time. When working on small pieces of SW the TDD strategy seems controllable. I believe that when a SW module is scaled up to a larger dimension the TDDs can be a stick in the wheel for the SW devep.
concern: triviality It seems unnecessarily trivial in many cases.
concern: unease I felt uneasy not thinking as much about implementation, like I'd forgotten my keys or left the oven on.
concern: unfamiliar the c++ part how does hardware fit in
concern: unnatural It feels 'fake' to have to write intermediate 'dummy' code/steps that you know are not going to cut it
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
concern: unplanned Perhaps a false sense of security if you "just get the test to pass".
concern: Unsure Didn't get to finish lab so not sure if there are others. Stuck at malloc area...
concern: Untested Getting ahead of oneself by writing code that doesn't yet have a test for it
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
concern: use in embedded needs initial effort
concern: useful vs practical How to put the approach into practice under the time constraint.
concern: Where are the requirements? Many failing test cases when requirements change later?
concern: Where are the requirements? - what's the starting point - how to construct the TDD tests - how to figure out what kinds of things need to tests
concern: Where are the requirements? 2. Is the starting point made good enough for the project.
concern: Where are the requirements? What is enough testing?
concern: Where are the requirements? I think is important to know the requirements before start with the deployment
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?
concern: Where are the requirements? To spend debugging test code instead of application code
concern: Where are the requirements? Small steps might lead to not think something obvious coming which may lead to change many codes and test cases.
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.
concern: Where are the requirements? I was little lost at the start without requirements
concern: Where are the requirements? Requires different design and development approach compared traditional when when have all the requirements up front
concern: Where are the requirements? need to write full test case
concern: Where are the requirements? I'm concerned about writing tests that ensure all functionality is checked.
concern: Where are the requirements? Requirements are sometimes unknown and at a higher level. TDD works on a small specific function, hard to see at a system level.
concern: Where are the requirements? If the test logic is flawed early on, it could lead to cases where tests are passing, but the functionality is not correct or requirements aren't met.
concern: Where are the requirements? Some of the hints are not very clear in how to help discern the answer.
concern: Where are the requirements? How I got the total over view about the requirement?
concern: Where are the requirements? May be hard to define requirements that are easily testable when interfacing with hardware? Maybe not.
concern: Where are the requirements? I felt like the requirements were not specific enough. we had to do some guesswork and we ended up "getting ahead".
concern: Where are the requirements? A test being inaccurate and not noticing (leaving something hardcoded)
concern: Where are the requirements? Getting to know the framework
concern: Where are the requirements? Often work is re-done as you aren't trying to think ahead
concern: Where are the requirements? I'd expect desired behaviour on overflow/underflow to be defined earlier.
concern: Where are the requirements? Test´s don´t really cover the full functionality. Production code can be faked easily
concern: Where are the requirements? We are moving forward from ant perspective of view. Implement before thinking may provide into blown up code.
concern: Where are the requirements? We have not yet tested non-functional requirements like speed and memory usage.
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.
concern: Where are the requirements? If I don't write good design notes and test plan outside the code, shortcuts could get left in the code, and I could miss important tests and implementation
concern: Where are the requirements? If I don't write good design notes and test plan outside the code, shortcuts could get left in the code, and I could miss important tests and implementation
concern: Where are the requirements? New kind of thinking. Test harness everytime availbale?
concern: Where are the requirements? More focused on just getting tests to pass rather than if the code actually works
concern: Where are the requirements? the number of steps to writing the test feels tedious at times
concern: Where are the requirements? When should I move on from testing interfaces into the internal implementation?
concern: Where are the requirements? Sometimes unsure whether or how test implementation details. e.g. static or dynamic memory allocation
concern: Where are the requirements? Tests driving functional correctness without addressing qualities such as performance.
concern: Where are the requirements? Wasn't clear where I was headed - should have read through all the test names first
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).
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.
concern: Where are the requirements? TDD seems to promote "hacking" at the problem instead of thinking about the requirements.
concern: Where are the requirements? Seems like a silly question: the test cases should have been formed from the requirements, I assume.
concern: Where are the requirements? Sometimes it looks a bit daunting if you have a lot of code to write.
concern: Where are the requirements? How to make sure we captured all behaviors? How to validate unit test framework for quality system?
concern: Where are the requirements? Hard to think of all edge cases of functions
concern: Where are the requirements? I worry that I'll forget a test, and miss an important requirement or edge case; focusing on one thing at a time is good, but TDD makes it easier for me to lose global perspective
concern: Where are the requirements? Hard to set the requirements for each case.
concern: Where are the requirements? If you may only implement code that's necessary to pass the tests, you end up with the same problem that you forget about corner cases and still have bugs in the code.
concern: Where are the requirements? If you may only implement code that's necessary to pass the tests, you end up with the same problem that you forget about corner cases and still have bugs in the code.
concern: Where are the requirements? How to use in a situation of unclear requirements/ interfaces. API changes and I have to rewrite all my testcases.
concern: Where are the requirements? this and that
concern: Where are the requirements? this is it
concern: Where are the requirements? you know it
concern: which-is-wrong Discerning if (when) the test is wrong instead of the code under test
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)
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
concern: wrong Add code that you know is wrong because the "right" behavior isn't yet needed.