Which task is performed because the test-driven development approach is being used?
Which task is performed because the test-driven development approach is being used?
In test-driven development (TDD), the process involves writing tests before writing the actual code. Once the test is written and fails (because the functionality is not yet implemented), the developer writes the minimum amount of code required for the test to pass. After the test passes, the code is then refactored to ensure it is clean and efficient while still passing the tests. The task of refactoring code that is covered by existing tests aligns with the principles of TDD, as it involves refining the code after it has already been tested to ensure it meets all requirements and maintains readability and structure without changing its behavior.
I would say C
So confused question. TDD definition says, that "The simple concept of TDD is to write and correct the failed tests before writing new code (before development). " But C also works for me
C. refactoring code that is covered by existing tests
I really struggle with this one because: A. creating test scenarios based on continuous development *technically - this is true because you write the tests, then prove they fail, then write code that passes the test. B. writing code without committing any coding violations This one is dumb and obviously not the right path. C. refactoring code that is covered by existing tests So according to the answer given in the main question, refactoring is what causes the old tests to fail because you make a change. D. testing existing software before developing new code Technically you're doing this all the time because you test each 'chunk' of code as you write it. I'm guessing that D is the 'most correct' but I can see how A,C, and D all would be correct.
Refactoring code doesn't make the old tests fails. What you are doing is improving code structure, readability and design. It shouldn't affect in anyway the logic and requirements of the code you already have. I would point to answer C and exclude D because of this.
I would say A. From Cisco Devnet course: Testing to validate (or initially, to clarify) design intention in light of requirements implies that we should write testing code before we write application code. Having expressed requirements in our testing code, we can then write application code until tests pass.
The answer is C because in a TDD approach, you first write the test-code, test the test-code and then write the production code. You do not test any existing software as is suppose to not exist, yet. Although what you do always through the TDD pipeline is refactor the code for the software that has been tested.
I'm sure it's D
C is the correct answer If you read the book you will found: "The idea is that you build a test case first, before any software has been created or modified" but "testing existing software before developing new code" is the idea or goal, not the task five steps of TDD: -Write a test -Test fails -Write some code -Test passes -Refactor
A. does not sound right because in TDD, a test should be created first before any development, so it is the development that will be based on the test. B. is utterly wrong. C. as stated in DEVNET: "Step 5. Refactor: Clean up the code as necessary, removing any test stubs or hardcoded variables used in testing. Refine the code, if needed, for speed" In my opinion, it should be C because in TDD once you create a test, you should develop a code for unit testing which D. is negating.
Correct answer is, C
C seems like it feets the most
I would say C because of the 5 TDD steps: Step 1. Write a test: Write a test that tests for the new class or function that you want to add to your code. Think about the class name and structure you will need in order to call the new capability that doesn’t exist yet—and nothing more. Step 2. Test fails: Of course, the test fails because you haven’t written the part that works yet. The idea here is to think about the class or function you want and test for its intended output. This initial test failure shows you exactly where you should focus your code writing to get it to pass. This is like starting with your end state in mind, which is the most effective way to accomplish a goal. Step 3. Write some code: Write only the code needed to make the new function or class successfully pass. This is about efficiency and focus. Step 4. Test passes: The test now passes, and the code works. Step 5. Refactor: Clean up the code as necessary, removing any test stubs or hard-coded variables used in testing. Refine the code, if needed, for speed. It should be nice to validate the application before making any changes, but it is asking about TDD.. so C is more correct in this case.
I would say C because of the 5 TDD steps: Step 1. Write a test: Write a test that tests for the new class or function that you want to add to your code. Think about the class name and structure you will need in order to call the new capability that doesn’t exist yet—and nothing more. Step 2. Test fails: Of course, the test fails because you haven’t written the part that works yet. The idea here is to think about the class or function you want and test for its intended output. This initial test failure shows you exactly where you should focus your code writing to get it to pass. This is like starting with your end state in mind, which is the most effective way to accomplish a goal. Step 3. Write some code: Write only the code needed to make the new function or class successfully pass. This is about efficiency and focus. Step 4. Test passes: The test now passes, and the code works. Step 5. Refactor: Clean up the code as necessary, removing any test stubs or hard-coded variables used in testing. Refine the code, if needed, for speed. It should be nice to validate the application before making any changes, but it is asking about TDD.. so C is more correct in this case.
TTD == Create test for what you want >> Run test on current code it fails >> Write code >> Run test, test passes >> Refactor. Based on this D and C are correct, but knowing Cisco they keep harping on creating a test first and having it fail.