Mockaroo is a great tool for creating test data, with lots of good options as well as extensive base data. Sometimes though, you need to build custom fields. Here are a few I have used recently.
The top items are lacking in sophistication, but they do get better I think. To do – replacing random with a better probability function, and adding some more as I progress through making up more test data.
|Decreasingly likely selection’||['A', 'B', 'C', 'D', 'E', 'F'].slice(0, random(1,6)).sample||Upper param for random is length of list to select from.|
|Slightly more realistic range of Title||if field('gender') == 'Male' then 'Mr.' else ['Ms.', 'Miss', 'Mrs.', 'Mrs', 'MRS', 'Dr', 'Dr.', ''].sample end||Assumes a gender field.|
|Male honorifics||['Mr', 'Mr.', '', 'MR', 'MR.', '', 'Dr.', 'DR.', ' ', 'Imam', 'Rabbi', 'Sir', 'Prof.', 'His Honour Judge', 'Lord' ].slice(0, random(1,15)).sample||No link to gender field. Note use of blanks to make values decreasingly common as you go to the right. Don’t infer anything from the ordering especially of religious titles. If ‘Rabnbi’ is too long, you can use ‘R.’ instead.|
|Female honorifics||['Mrs', 'Mrs.', '', 'MRS', 'MRS.', '', 'Dr.', 'DR.', ' ', 'Imam', 'Rabbi', 'Lady', 'Prof.', 'Her Honour Judge', 'Lady' ].slice(0, random(1,15)).sample||Follows same probability distribution as male list.|
|Gendered Honorifics based on the above.||if gender == 'Male' then _title_male else _title_female end|
|Month names||['JAN', 'FEB', 'MAR', 'APR', 'MAY', 'JUN', 'JUL', 'AUG', 'SEP', 'OCT', 'NOV', 'DEC'][month(__dob)-1]||Used for Oracle import.|
|Oracle date format||format(day(__dob),0) + "-" + ['JAN', 'FEB', 'MAR', 'APR', 'MAY', 'JUN', 'JUL', 'AUG', 'SEP', 'OCT', 'NOV', 'DEC'][month(__dob)-1]+ "-" + format(year(__dob),0)||Use as a formula field.|
I’m doing a lot of code reviews at the moment and thought I’d write up some thoughts on simplifying c# code.
What is simple code?
simple code is code that amongst other things
* fits on a single screen
* can be understood pretty much at a glance.
* has simple logic
* has well-understood side effects – preferably none
* often make use of LINQ.
Why write simple code?
- Simple code can be understood quickly.
- Simple code can be checked for correctness.
- Simple code can be tested easily.
When are you done?
There are tools to measure how complex your code is (google Cyclomatic complexity for examples) but for my purposes, once you have met the requirements in the first list, you’re there!