1
00:00:06,280 --> 00:00:11,590
Hey everybody Caleb Stoltze here with Deb's Loeb's dot com and I'm here with a very quick video on UI

2
00:00:11,590 --> 00:00:12,990
testing best practices.

3
00:00:13,000 --> 00:00:17,920
These are just some things that we're going to keep in our mind as we are going throughout this section

4
00:00:17,920 --> 00:00:21,540
of content and these are just best practices to keep in mind.

5
00:00:21,550 --> 00:00:26,820
And a lot of them are sort of no brainers just basic principles for writing good code.

6
00:00:27,040 --> 00:00:31,480
But if you have any experience with unit testing a lot of these best practices are the same.

7
00:00:31,480 --> 00:00:33,340
So let's dive right in.

8
00:00:33,340 --> 00:00:37,940
Number one do not rely only on UI testing automation.

9
00:00:37,970 --> 00:00:41,380
OK you should still be running your app in a simulator of some kind.

10
00:00:41,380 --> 00:00:46,000
Or on localhost if you're doing web development you should still be interacting with it from time to

11
00:00:46,000 --> 00:00:50,890
time to ensure that everything works because you're testing like unit testing it's not perfect.

12
00:00:51,010 --> 00:00:51,560
It's great.

13
00:00:51,580 --> 00:00:52,410
It's helpful.

14
00:00:52,450 --> 00:00:55,180
It works most of the time but it's not perfect.

15
00:00:55,180 --> 00:00:59,300
So that is number one do not rely only on UI testing automation.

16
00:00:59,590 --> 00:01:06,730
Number two never pause threads or use timers in your test unless there are specific test requirements

17
00:01:06,730 --> 00:01:08,310
that you're given to do so.

18
00:01:08,590 --> 00:01:15,340
There is a very special way in in unit testing and UI testing to essentially pause your test to wait

19
00:01:15,370 --> 00:01:16,600
before continuing.

20
00:01:16,600 --> 00:01:21,550
And they're called expectations that's what we're going to talk about later in this section but never

21
00:01:21,550 --> 00:01:27,360
use thread or never pause threads or use timers unless you're explicitly told to do so.

22
00:01:27,370 --> 00:01:30,580
Number three name your tests wisely.

23
00:01:30,640 --> 00:01:31,810
OK this just makes sense.

24
00:01:31,810 --> 00:01:34,220
Like a function for instance you're going to name it wisely.

25
00:01:34,240 --> 00:01:38,810
A self-descriptive idea about the exact functionality being tested.

26
00:01:38,830 --> 00:01:44,080
Your test names should have names like that you need to tell exactly what you're testing.

27
00:01:44,080 --> 00:01:50,560
What I like to do of course you have to start your test with the word test and then I like to describe

28
00:01:50,560 --> 00:01:56,650
right after that what I'm testing so I might say test log in button and then I like to put an underscore

29
00:01:56,650 --> 00:02:03,850
and say the condition or what is happening so when tapped then I put another underscore and then say

30
00:02:03,850 --> 00:02:04,810
the expected result.

31
00:02:04,810 --> 00:02:12,100
So test log and Button underscore when tapped underscore should animate and then I would test my animations

32
00:02:12,100 --> 00:02:13,990
with my testing which is very cool.

33
00:02:13,990 --> 00:02:16,840
So number three is name your test wisely.

34
00:02:16,840 --> 00:02:21,500
Number four make tests simpler instead of adding comments.

35
00:02:21,580 --> 00:02:27,240
If you're needing to add a bunch of comments to explain what your test is testing your test is too complicated.

36
00:02:27,310 --> 00:02:28,200
Make it simpler.

37
00:02:28,330 --> 00:02:33,790
Maybe instead of writing a huge block of code explaining what it all does maybe put that into a function

38
00:02:33,820 --> 00:02:36,260
and just call that function from your test.

39
00:02:36,280 --> 00:02:38,580
Your test should be very simple and easy to read.

40
00:02:38,820 --> 00:02:43,160
Ok number four make your test simpler instead of adding comments.

41
00:02:43,210 --> 00:02:44,160
Number five.

42
00:02:44,350 --> 00:02:46,010
All tests pass.

43
00:02:46,160 --> 00:02:51,460
OK that is a policy that you should strictly adhere to if you are utilizing tests because if you allow

44
00:02:51,460 --> 00:02:54,020
test to fail what's the what's the point of using them.

45
00:02:54,370 --> 00:03:00,850
All tests should pass and be green before being admitted into your master repository.

46
00:03:00,850 --> 00:03:01,620
So number five.

47
00:03:01,720 --> 00:03:03,250
All tests pass.

48
00:03:03,250 --> 00:03:04,280
Number 6.

49
00:03:04,330 --> 00:03:10,310
Every test should be independent meaning one test should not rely on another test in order to pass.

50
00:03:10,330 --> 00:03:18,040
Each test should be an individual cut piece that is allowed to run on its own get its own result and

51
00:03:18,040 --> 00:03:20,330
not rely on any other tests.

52
00:03:20,950 --> 00:03:21,670
Number six is.

53
00:03:21,670 --> 00:03:23,720
All tests should be independent.

54
00:03:23,860 --> 00:03:30,300
Number 7 use the console and make sure to set up some type of reporting in case of test failure.

55
00:03:30,310 --> 00:03:38,140
Right now of course there are ways to do this very easily with the UI testing framework in iOS and we're

56
00:03:38,140 --> 00:03:39,930
going to be looking at that in just a moment.

57
00:03:40,030 --> 00:03:44,610
But make sure that you can report some way to basically tell you what's going on.

58
00:03:44,610 --> 00:03:49,900
If your test fails instead of just saying it failed have it tell you why it failed and then this is

59
00:03:49,900 --> 00:03:51,540
not necessarily a best practice.

60
00:03:51,550 --> 00:03:53,050
But I just thought it was a neat idea.

61
00:03:53,050 --> 00:03:56,800
I read about it on line and I learned that this is something that you can do.

62
00:03:57,190 --> 00:04:04,630
You can basically set it up so that when your test fails the you can actually see like a screenshot

63
00:04:04,720 --> 00:04:06,310
on the screen of what happened.

64
00:04:06,330 --> 00:04:11,830
OK so you can actually take screenshots in your test for failure investigation so if you're like looking

65
00:04:11,830 --> 00:04:16,720
into why it failed you can have a screenshot to refer to for exactly when the test fails you can see

66
00:04:16,720 --> 00:04:21,770
if maybe something is off centered or maybe if something is not animated properly you can tell with

67
00:04:21,770 --> 00:04:22,650
the screen shot.

68
00:04:22,750 --> 00:04:23,410
Very cool stuff.

69
00:04:23,410 --> 00:04:30,610
So these are some basic best practices for UI testing and now we're actually going to dive into an example

70
00:04:30,610 --> 00:04:34,650
of a very very basic UI test in swift Acia there.