Change Details

CheckUser code currently doesn't support unit testing. This feature should be added, and alongside it a test data set should also be generated. The test data set can be extended and repurposed, such that it can be used for creating any additional extensions (e.g. a JS code that uses CU tool via API). Having a relatively extensive set of test data can be extremely beneficial. The task is created in reaction to notable support for this idea on the cu-l listserv. One of the users on the listserv also made suggestions about what the test data should contain, which is pasted below: * Users * Sample users and anons whose edits are to be checked * Sample CU users whose names appear in log and who can run tests ** with admin rights ** without admin rights (different interface) ** special: oversight, steward -- is it neccessary? * Sample non-CU users who fail to use the tool * Users with constant or almost constant IP and UA for a simple case * Useres who often change their data (both users with dynamic IP from an ISO with multiple domains and sofisticated vandals) * Multiple users from same IP * IPs ** IPv4 ** IPv6 ** Some similar from a same domain ** Some different ** Blocked, previously blocked and not blocked * User agents ** Common from a few operating systems and browsers (useful to keep up-to-date) ** A few complicated ones ** Some known bots (AWB or Pywikibot) ** Fake *Edits ** Logged-in ** IP ** From behind proxy / open proxy ** Newr than 3 months ** Older than 3 months * Edit summaries and check reasons -- I am not sure if they are impoertant for testing and experimenting * Pages of course that were edited -- I don't hink this needs extra considerations

CheckUser code currently doesn't support unit testing. This feature should be added, and alongside it a test data set should also be generated. The test data set can be extended and repurposed, such that it can be used for creating any additional extensions (e.g. a JS code that uses CU tool via API). Having a relatively extensive set of test data can be extremely beneficial. The task is created in reaction to notable support for this idea on the cu-l listserv. One of the users on the listserv also made suggestions about what the test data should contain, which is pasted below: * Users * Sample users and anons whose edits are to be checked * Sample CU users whose names appear in log and who can run tests ** with admin rights ** without admin rights (different interface) ** special: oversight, steward -- is it neccessary? * Sample non-CU users who fail to use the tool * Users with constant or almost constant IP and UA for a simple case * Useres who often change their data (both users with dynamic IP from an ISO with multiple domains and sofisticated vandals) * Multiple users from same IP * IPs ** IPv4 ** IPv6 ** Some similar from a same domain ** Some different ** Blocked, previously blocked and not blocked * User agents ** Common from a few operating systems and browsers (useful to keep up-to-date) ** A few complicated ones ** Some known bots (AWB or Pywikibot) ** Fake * Edits ** Logged-in ** IP ** From behind proxy / open proxy ** Newr than 3 months ** Older than 3 months * Edit summaries and check reasons -- I am not sure if they are impoertant for testing and experimenting * Pages of course that were edited -- I don't hink this needs extra considerations

CheckUser code currently doesn't support unit testing. This feature should be added, and alongside it a test data set should also be generated. The test data set can be extended and repurposed, such that it can be used for creating any additional extensions (e.g. a JS code that uses CU tool via API). Having a relatively extensive set of test data can be extremely beneficial. The task is created in reaction to notable support for this idea on the cu-l listserv. One of the users on the listserv also made suggestions about what the test data should contain, which is pasted below: * Users * Sample users and anons whose edits are to be checked * Sample CU users whose names appear in log and who can run tests ** with admin rights ** without admin rights (different interface) ** special: oversight, steward -- is it neccessary? * Sample non-CU users who fail to use the tool * Users with constant or almost constant IP and UA for a simple case * Useres who often change their data (both users with dynamic IP from an ISO with multiple domains and sofisticated vandals) * Multiple users from same IP * IPs ** IPv4 ** IPv6 ** Some similar from a same domain ** Some different ** Blocked, previously blocked and not blocked * User agents ** Common from a few operating systems and browsers (useful to keep up-to-date) ** A few complicated ones ** Some known bots (AWB or Pywikibot) ** Fake * Edits ** Logged-in ** IP ** From behind proxy / open proxy ** Newr than 3 months ** Older than 3 months * Edit summaries and check reasons -- I am not sure if they are impoertant for testing and experimenting * Pages of course that were edited -- I don't hink this needs extra considerations