Test Driven Development Flashcards

1
Q

What is test driven development?

A

Test Driven Development (TDD) is a development model where the tests for a function / system are written first and then the code is written to match what is expected of a test.

After success of the test and code for the first requirement, we write another test case to fulfil another requirement and repeat the cycle.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What are the advantages of test driven development?

A
  • Since code is only added as needed to meet the requirement of the test, the solution tends to have only code required to solve the problem – minimizes redundant code.
    • Code tends to be refactored after new tests are added.
  • The amount of code written in total can be greater than non TDD environments, but developers claim there is little requirement to use a debugger.
  • Since a Test case is written first, it ensures the each code path has at least one test case. Better coverage.
  • Modifications to the code in future will require a full set of test passes before the modification can be accepted.
    - We always have a set of regression tests.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is the test driven development cycle?

A
  1. Add a test
  2. Run all tests and see if the new one fails
  3. Write some code
  4. Run tests
  5. Refactor code
  6. Repeat
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are Testing Driven Developments shortcomings?

A
  • Ideal for small component testing. Not ideal for full functional testing (UI testing/Database Testing).
  • Management Support is required. Management sometimes feels writing tests is wasting development time. Studies show that debugging time is reduced when TDD is used.
  • The tester and developer are the same person.
    - Tests may suffer the same issues as code. If the developer has a blind spot in terms of requirements it may not show up as a test case.
  • Tests need to be maintained.
    - Detail must be provided early to ensure all test cases can be developed early. This model may not be as well suited to developing code with frequent design changes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How would you make a test that failed if the test took longer than 5 seconds to run?

A

@Test (timeout=5000)

put that at the beginning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

How would you make a test handle an exception it is supposed to throw?

A

@Test(expected=IllegalArgumentException.class)

put that at the beginning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What would the syntax look like when you needed to test for a time period and an exception?

A

@Test (expected=IllegalArgumentException.class,timeout=5000)

at the beginning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

When would you need to create your own little algorithm in a test instead of hard coding?

A

Only in the example where there was randomly generated and was testing for unique elements only.

all of the other types could have been hard coded

How well did you know this?
1
Not at all
2
3
4
5
Perfectly