Assuming that you're working in a US environment (the zip code being in US format) and that your application specifications don't call out whether or not a zip 5+4 should be accepted:
I'd report this as a bug if:
Your specifications/user stories call for any or all valid US zip codes to be accepted (this is an implicit requirement to accept ...
I would split your question into two parts:
What needs to be tested?
You have already covered some critical scenarios. Besides these following should also be covered-:
-Ensure that all expected data is loaded into target table.
-Compare record counts between source and target.
-Check for any rejected records
-Null, non-unique or out of range ...
Data Validation is a very important part of any testing strategy for an application that is dependent on data. There are two things you should do:
Validate data in your test environment
You will have to have a way to generate real world scenarios for your application, hopefully your functional testing will already have this covered.
Based on the known ...
How complicated is the ETL logic? Are you bringing over every record? Do you transform the data? I would create targeted test data to test the logic itself.
Once you know what you know exactly which kind of data is brought over and exactly how the data is transformed you can absolutely automate it. Start with an empty database, insert to source for your ...
I think you have several directions you can potentially take here, based on the information you've given, but all of them require a degree of modification to standard unit testing structures.
Some unit test frameworks allow you to identify a data source and will run a given test once per record. If these read each record one at a time, this will work for ...
It is definitely a bug, unless your requirements mention that ZIP extension should be ignored. So talk to your customer how to handle it. One possibility is to silently strip the extension if you don't need it.
As there are to many characters to test them all. You need to think about how many cases you need to safe-guard.
I think only two cases are needed to document the behavior
one with special characters
one without special characters
I would try a couple different characters and combinations when doing exploratory testing sessions, but not create test-...
For example, we have the following table:
mysql> describe city;
| Field | Type | Null | Key | Default | Extra |
| ID | int(11) | NO | PRI | NULL | auto_increment |
| Name | char(35) ...
The Big List of Naughty Strings is another good one - it's not just diacritics, but a whole lot of different unicode strings and a bunch of other strings that are known to cause problems in different applications.
(I am not affiliated - I just use it a lot)
CSVDiff may help you.
csvdiff --style=summary id a.csv b.csv
1 rows removed (20.0%)
1 rows added (20.0%)
2 rows changed (40.0%)
And you can save the results in a file. Pretty printing is easy; ...
This will depend on a number of factors, including: time/budget, data quality policy of your organization, data quality of the source dataset, complexity of each layer, etc.
A general guideline is, as with any testing, to ask yourself "what could go wrong here?" at each step.
For example, you could do data integrity at 1 and 2. But if you had a low budget ...
Liquibase is a tool that offers this kind of functionality among others, assuming you can establish jdbc connections to your databases.
There is a diff command that takes the connection parameters of 2 databases, and it reports their differences.
In order to report data changes you will need to use the --diffTypes=data option.
The best way to ensure the completeness and correctness of data is by testing it in SQL.
Can you try creating a database on your machine and use import\export wizard in SQL server and import the source and target file in two tables? I think then you will be able to validate the data transformation and ETL logic
I am also curious to know if there is any ...
@Agree to Yu. I will use following approach:
We have text
If its with special characters we can verify :
When above case 1 failed - Means your string doesn't contains special characters
Note - You need to verify all special characters in loop if more in numbers
I have found another solution by using Burp proxy tool that helped me to bypass JS validation on a client, intercept the request that has been sent to the server, alter it and forward back to server.
That way I was able to test exactly what I needed.
We typically call this type of testing (or technique) equivalence class or equivalence class partitioning. In a nutshell equivalence class partitioning means certain groups of input or stored data are treated the same by the program.
We can break these equivalent values into groups and select a few from each group to test with. Each test is ...
Why don't you try using regular expression.
Sample regular expression can be:
One regular expression should identify all combinations.
P.S: Regular expression given about is not really accurate. But as per answer to your question. Regular expression is batter way to handle this.
XML Schema Assertion uses javax.xml.parsers.DocumentBuilder.parse() method which stops parsing XML file after the first error.
You can work it around by implementing your own ErrorHandler in i.e. Beanshell Assertion
Add Beanshell Assertion instead of the XML Schema Assertion
Put the following code into the Beanshell Assertion "Script" area: