2. Who is Annette Allen
DBA/Dev for 14 years
Joint Chapter Leader of SQL South West based in the South
West of England
Event organiser
Friend of Red Gate
UK Regional Mentor
13. Requirements
“I need a car that is under 5 years old, costs less than £10k can
do more than 40mpg and can take 4 people”.
14. Tests
1. Price is under £10k
2. Age is under 5
3. Seats >= 4
4. Fuel economy > 40 mpg
15. Acceptance Criteria
The car must be under 5 years old
The car must cost less than £10k
The car must have at least 4 seats
It must do at least 40 mpg
16. What have we learned?
Ask questions
Ensure no misunderstanding
Confirm requirements
Measurable
Quantifiable
18. Requirements gathering
Applicant = flag in system
Current = applied for intake to start September 2016
Good = must have at least 3 predicted A Levels at AAA, AAB or
ABB
19. Tests
Applicant = Yes
Start Date > 1 September 2016
Predicted grade tests x 4:
AAA is included
AAB is included
ABB is included
BBB is excluded
21. How do we test
tSQLt
Community tool
Licence free
Redgate SQL Test
Fully licenced and supported product
Part of the Developer suite
22. Using tSQLt
Test Class
All tests must start with the word ‘test’
Names should define what’s being tested
Tests should test 1 thing and 1 thing only
24. How does this work?
Fake everything
Functions
Data
All other objects relied upon by the object tested
25. What is Test Driven Development
Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development
cycle: first the developer writes an (initially failing) automated test
case that defines a desired improvement or new function, then
produces the minimum amount of code to pass that test, and
finally refactors the new code to acceptable standards. Kent Beck,
who is credited with having developed or 'rediscovered'[1] the
technique, stated in 2003 that TDD encourages simple designs and
inspires confidence.[2]
Taken from Wikipedia – Nov 2015
3 main reasons,
To prove that the code is working as expected
To have confidence in code we have written
Give us the ability to change code knowing that what we have amended will not introduce errors when deployed
So broken car = can’t get anywhere
So husband is away I decide to go car shopping
Go the garage and hey I’ve just had a PPI claim so I decide to buy my dream car
When husband gets home he’s not as excited by me.
It’s not practical, economical or cheap in any way.
It’s fun though
What tests would we write?
What’s missing from this statement?
What defines a child and who should get presents?
Must be on Father Christmas’ nice list, he’s updating the details throughout the year and has an undecided box until Christmas Eve
Father Christmas would need a report showing who is undecided to ensure he can categorise them
When designing this it took many goes to work out the actual requirements. When should they be under 16, what is deemed nice.
For example they should be under 16, when on Christmas Day, Today, January 1st. This all needs to be defined and questions need to be asked.
What have we missed?
Possible test for children who are 17 are not returned
Need to test for multiple rows
Before we can start writing tests we need to know the criteria to which they must match
Our requirements become our acceptance criteria which in turn becomes our tests
For each item in our acceptance criteria it will become a test:
Less than 5 years old
Less than £10k
More than 40 mpg
Able to take 4 people comfortably
Real world example, returning data within half second –does the company have the resource to throw at the hardware required for this?
What about those students who have 4 predicated Grades, currently those tests may exclude those so we have to ensure that tests are written to include those.
You can now see how lists of tests can build up, but without that we may have given the wrong results but excluding those with 4 predicted grades.
tSQLt – written by Sebastian Maine and Dennis Lloyd, completely free
Redgate SQL test - they used tSQLt but put a nice front end on it. Included in Developer suite and is paid for. Trial version available. I have a licence to give away during th
is session.
All on Test/development server, this should not occur on a production environment
A test class is a collection of tests
Named after the object they are testing
e.G Function GetListOfPracticalCars
The class name is the name of the object e.g. GetListOfPracticalCars
The test name is a description of what the test is carry out
You do need set trustworthy on however test is only run on test/dev boxes. Tests should NOT be run on prod dbs
Fake every object our test subject interacts with
Idempotent!!!
It is infinitely repeatable with the same result
Fake all surrounding objects so that you can control their interaction with the test subject and then you know that any changes have been introduced by your changes in code and no external factors.
Otherwise known as TDD
Work out what tests are required as a team
Then create a stub for what you are testing e.g. stored procedure
Then write all the tests
Which will all fail
Then write the stored procedure
Run all the tests