You need to test isPrime(n) with 20 different input values. What JUnit feature avoids writing 20 separate test methods?

Your team follows this Git workflow: main is production-ready, develop integrates features, individual feature/* branches for new work. You’re starting work on user authentication. What is the correct workflow?

What is the key difference between Sprint Review and Sprint Retrospective?

Your payment system supports Credit Card, PayPal, and Bitcoin. Each has different processing logic. Which pattern best organizes this?

Assume you have the following JavaDoc for a method: /** * Determines water usage tier for billing. * * – gallons must be non-negative, otherwise throws IllegalArgumentException * – Tier 1: 0-5000 gallons: $0.01/gallon * – Tier 2: 5001-10000 gallons: $0.015/gallon * – Tier 3: 10001-20000 gallons: $0.02/gallon * – Tier 4: 20001+ gallons: $0.03/gallon * * @param gallons water usage in gallons * @return tier number (1, 2, 3, or 4) */ public int getWaterUsageTier(int gallons); For the above example you should do a detailed Black-box test design. Create Equivalence Partitions and do a Boundary Value analysis – describe.  Taking these into account design at least 6 test cases that you think are most important based on your partitions (I do not want Java code here, I want your test description). Make sure you mention the partitions and/or BV in the test cases you design. Then write one Unit Test (the syntax does not have to be 100% correct but should of course be in Java).

In Assignment 3 Task 3, you implemented processOrderItem() AFTER writing tests for it in Assignment 2. Your classmate says: “Writing tests first is slower – I implement first, then write tests to match my code.” What are valid counterarguments?Mark all that apply

In JUnit, you use @BeforeEach to set up test data before each test method runs. What is this called and why use it?

Assume you have the following JavaDoc for a method (from Assignment 3): /** * Processes an order item and calculates subtotal. * * – quantity must be 1-100, otherwise throws IllegalArgumentException * – pricePerUnit must be positive, otherwise throws IllegalArgumentException * – Discount rules: * – quantity 1-5: no discount * – quantity 6-20: 10% discount * – quantity 21-100: 20% discount * – Returns: quantity * pricePerUnit * (1 – discount) * * @param quantity number of items * @param pricePerUnit price per single item * @return calculated subtotal */ public double processOrderItem(int quantity, double pricePerUnit); For the above example you should do a detailed Black-box test design. Create Equivalence Partitions and do a Boundary Value analysis – describe.  Taking these into account design at least 6 test cases that you think are most important based on your partitions (I do not want Java code here, I want your test description). Make sure you mention the partitions and/or BV in the test cases you design. Then write one Unit Test (the syntax does not have to be 100% correct but should of course be in Java).

Your white-box tests achieve 100% node coverage but only 75% edge coverage for a method. What does this indicate?

During a merge, Git shows conflicts in 5 files. You want to keep ALL changes from the incoming branch for Config.java. What is the quickest approach?