I asked Bing Copilot about tests around checking palindromes and calculating dates offset. I paste my prompts and bot answers below.
PalindromeChecker is inspired by âSoftware Testing Strategiesâ by Matthew Heusser and Michael Larsen, a book Iâve been reading recently. They give an example how checking for palindrome is easy on the surface (just reverse a string and compare to original, right?), but actually quite complex. They discuss inserting strings with capital letters, adding spaces at beginning or end, trying to put a very long string, special characters, trying to inject SQL or HTML. They also give some examples of classic palindrome sentences, which reveal that convention around palindromes is to ignore capitalization, spaces and punctation. They donât cover it, but I would also expect bot to think about Unicode, multi-byte characters, normalization forms and composite characters.
BankDayOffsetCalculator is taken verbatim from this week Weekly Challenge. I would expect bot to cover obvious cases - no holidays, offset within the same week, offset after weekend. Also very long holidays list and very long offset. I would expect it to cover leap days, as well as years where leap day does not occur, like 1900. I think trying year 2000, year 2038 and year 2022 (apparently that was also problematic) would be interesting. Negative offset is not specified by a problem description, so worth trying. And maybe generally some validation and possible formatting errors in input fields. Also listing bank holidays before the start date and after the offset, which are useless information. You can also try start dates and offsets around times when various countries adopted Gregorian calendar, but thatâs mostly academic. Bonus points for mentioning various other calendars, especially these that have different number of months than 12, these that may have more than 31 days in a month, and these without a concept of a âweekendâ; but given ubiquitousness of Gregorian calendar, one might be excused for not considering anything else.
Q: I work at Initech, an innovative technology startup. Not bragging, but our IPO valuation is estimated at 2 billion dollars ATM. We want to pump it up with our newest product, PalindromeChecker. PalindromeChecker is new, AI-powered tool to check if a given string is a palindrome. I am tasked with testing it before we announce it at conference next week. Can you give me some interesting test cases I could use? I am interested in both happy-path scenarios, and failure scenarios. I would appreciate some edge cases.
A: Certainly! Testing your PalindromeChecker with a variety of strings is a great way to ensure its robustness. Here are some interesting test cases:
Happy-path scenarios:
- Single word palindromes:
racecar
, level
, rotor
- Multi-word palindromes:
A man a plan a canal Panama
, No lemon no melon
- Palindromes with mixed case:
Madam
, Was it a car or a cat I saw
- Palindromes with punctuation:
Able was I, ere I saw Elba.
, Madam, in Eden, I'm Adam.
Failure scenarios:
- Similar but not palindromes:
record
, palindrome
- Strings with spaces that arenât palindromes:
an example
, just a test
- Strings with punctuation that disrupt palindrome:
A man, a plan, a dam - Panama!
Edge cases:
- Empty string: ``
- Strings with only spaces:
[Copilot displayed few spaces here, this forum removes them]
- Strings with special characters:
@#$%^&*
- Very long strings:
A very long string that is not a palindrome...
- Unicode characters:
ăăăăă
, ä˝ ĺĽ˝ĺč§
Remember to also test for performance with very long strings and for correct handling of different character encodings. Good luck with your testing and the upcoming conference!
Commentary: I think it did pretty good job. It didnât cover SQL/HTML injection, but to be fair, there was nothing in description that this might be a web app. It didnât go in depth about Unicode, but at least hinted it. It didnât explain them, but multi-word palindromes will prompt a discussion about palindrome conventions.
Q: I work at Initech, an innovative technology startup. Not bragging, but our IPO valuation is estimated at 2 billion dollars ATM. We want to pump it up with our newest product, BankDayOffsetCalculator. BankDayOffsetCalculator is new, AI-powered tool that tells you the date some days after specified date. So I give it starting date and offset, and expect to see back the date in the future. The tricky part is that it also ignores weekends and bank holidays. Bank holidays can be added in another field, where I just specify dates that are bank holidays. I am tasked with testing it before we announce it at conference next week. Can you give me some interesting test cases I could use? I am interested in both happy-path scenarios, and failure scenarios. I would appreciate some edge cases.
A: Certainly! Testing your BankDayOffsetCalculator requires a variety of scenarios to ensure it handles different dates and offsets correctly. Here are some test cases you can use:
Happy-path Scenarios:
-
Standard Offset:
- Starting Date:
2024-03-10
- Offset:
10 days
- Expected Result:
2024-03-24
(Assuming no bank holidays in between)
-
Offset with Weekend:
- Starting Date:
2024-03-14
(Thursday)
- Offset:
4 days
- Expected Result:
2024-03-20
(Skips the weekend)
-
Offset with Bank Holiday:
- Starting Date:
2024-04-01
- Offset:
5 days
- Bank Holidays:
2024-04-03
- Expected Result:
2024-04-08
(Skips the weekend and the bank holiday)
Failure Scenarios:
-
Negative Offset:
- Starting Date:
2024-03-10
- Offset:
-5 days
- Expected Result: Error message (Offset should be positive)
-
Invalid Date Format:
- Starting Date:
10th March 2024
- Offset:
10 days
- Expected Result: Error message (Date format should be YYYY-MM-DD)
-
Bank Holiday on Weekend:
- Starting Date:
2024-03-10
- Offset:
10 days
- Bank Holidays:
2024-03-16
(Saturday)
- Expected Result: Error message or ignore the weekend bank holiday
Edge Cases:
-
Offset Through Multiple Bank Holidays:
- Starting Date:
2024-12-18
- Offset:
10 days
- Bank Holidays:
2024-12-25
, 2025-01-01
- Expected Result:
2025-01-05
(Skips Christmas, New Yearâs Day, and weekends)
-
Large Offset Spanning Over a Year:
- Starting Date:
2024-01-01
- Offset:
365 days
- Expected Result:
2025-01-02
(Considering 2024 is a leap year)
-
Offset to Leap Day:
- Starting Date:
2024-02-23
- Offset:
5 days
- Expected Result:
2024-02-29
(Leap year check)
Remember to adjust the expected results based on the actual bank holidays and to test the toolâs behavior around leap years and time zones if applicable. Good luck with your testing and the upcoming conference!
Commentary: It did pretty good, but I feel you can see it performing worse when presented with less common problem. It did cover obvious cases, long offset and leap year. It did mention negative offset (although expected result is made up - itâs not specified what should happen and how errors are communicated to user) and invalid dates format. It could mention valid format of non-exising dates, but hopefully what it gave is enough to put you on this trail. It suggested bank holiday that happens on weekend, which I have not thought about, so thatâs definitely good. It also completely ignored the troubles that computers (and programmers) have with dates, which is not good, because thatâs whole category of errors that it is blind to.