Writing unit tests based on the following specifications/requirements. series of unit tests to test a function called credit_card_validator (written for
Writing unit tests based on the following specifications/requirements.
- series of unit tests to test a function called credit_card_validator (written for you) that is passed a sequence of digits as a string that represents a credit card number. This function will return True if it is a valid credit card number, otherwise, it will return False.
- Depending on the credit card issuer, the length of a credit card number can range between 10 and 19 digits.
- The first few digits of the number are the issuer prefix.
- Each credit card issuer has an assigned range of numbers.
- For example, only Visa credit card numbers may begin with 4, while American Express card numbers must begin with either a 34 or 37.
- Sometimes, credit card providers are assigned multiple ranges. For example, MasterCard card numbers must start with the numbers between 51 through 55 or 2221 through 2720 (both ranges are inclusive).
- The last digit of the number is referred to as the check digit and acts as a checksum. Most credit cards calculate this check digit using the Luhn algorithm (see resources below for how this is calculated).
- In order to limit the scope of this assignment, we are going to limit the number of credit card issuers to 3: Visa, MasterCard, and American Express. Each has its own prefixes and length requirements.
- Prefix(es): 4
- Length: 16
- Prefix(es): 51 through 55 and 2221 through 2720
- Length: 16
- American Express
- Prefix(es): 34 and 37
- Length: 15
Need a series of tests that attempt to reveal bugs in the implementation. As this is black-box testing, you will not have access to the source so you must use what you have learned this week to generate test cases.
You will need to locate all 10 bugs in the code (refer to the rubric for full details).
Some are easier than others. Bug 5 is easy to miss without using Partition Testing and Bug 6 requires using what you know about common errors to design your tests
You are free to determine how you generate your test cases. You may do it completely manually or use an automated tool like the TSLgenerator.
Ensure you have test cases that cover the input domain. This means that at the very least, you need to have a test case for each of the prefix ranges listed above.
For this assignment, you are prohibited from using Random Testing.
Use only these Black Box Testing techniques: Error Guessing, Partition Testing, and Boundary Value Testing.
It is best to only have a single assert in any test. Once one fails, the rest of the code in the test isn't executed.
- Your test cases should be selected manually and not programmatically
- You may assume only strings are being sent to credit_card_validator and that any character contained therein will be a digit.
- You will need to use from credit_card_validator import credit_card_validator in your tests.py
- To ensure your tests are correctly importing the function for testing, you may put the following dummy code into a file called credit_card_validator.py