Abbey Jackson

Hmmm…. 🧐

This will probably come as a shock but this “website” is actually hosted on Tumblr and I set it up about 6 years ago. It seems as though something has changed with Tumblr’s formatting as all of the posts are running on top of each other as you scroll down the page…

Unless I make a new post which somehow magically fixes it. I even tried making a post - see it’s fixed - then delete the useless post and wouldn’t you know the bug showed up again. I don’t have anything real to post about though so I’m just posting about having to make this post in order to fix the problem…


The problem with iOS bootcamps

Published August 20, 2017 on LinkedIn: https://www.linkedin.com/pulse/problem-ios-bootcamps-abbey-jackson/

When moving my articles onto this new site I have not edited them except to fix broken links or incorrect information. I like to preserve the original mood, bad grammar and all!


https://pixabay.com/en/man-board-drawing-muscles-strong-2037255

There is a good chance what I am about to share with you applies to other kinds of programming bootcamps as well but as I am iOS specialized I really can’t pretend to know what is needed for a career on any other platform.

I am a bootcamp grad and I would not change the path I took. It was the right path for me and I think it can be the right path for many people but they need to go into it with an awareness of the drawbacks of bootcamps – and there are many drawbacks.

My path

I went from Nanny to iOS Developer at a Fortune 100 company working on very cool unannounced tech in 18 months without ever being pegged a junior. I am what you could consider a success story for my bootcamp – for the entire bootcamp model really. I was the only student in my class that got a proper iOS job with a competitive (local) salary upon graduation (not counting two students who were promised jobs before they started).

This didn’t happen because of my bootcamp though, at least not directly. The bootcamp gave me the launching pad I needed to create these opportunities for myself. I have worked hard to create these opportunities including being involved with new developer training and doing projects on the side for clients and non-profits. I have a lot of teaching experience in previous careers and so I enjoy mentoring and have found myself the go-to person for developers onboarding onto our projects at work – and even find myself helping out new devs in other offices remotely. Recently my bootcamp asked me to become an instructor (I had to decline due to scheduling).

Outside of work I started a non-profit called CodeDoesGood with 3 friends. I have constantly sought out opportunities for growth and learning both at work, in my evenings online, and through side projects. I’m only 2 years into my career now, and I still have a lot to learn, but I know senior developers who come to me with questions because I’ve had a chance to study and be exposed to more than they have.

The common path

So yeah, you can launch a successful career from a bootcamp, bootcamps aren’t a bad thing necessarily. The more common scenario though is one where you spend 6 months (or more) trying to find a job, when you get a job you are either the only iOS developer there or you are in an environment where no one wants to mentor you. After a stressful 3-12 months you either quit or are let go because you can’t match the performance they want from you – because they’re not helping you understand what you need to do to make that performance. I know 5 bootcampers this happened to and have read countless other accounts like this.

Or possibly you do land a stable job but you are given simple bug fixes and UI tasks where you are never really challenged.

Or even worse you are the only dev and think you are killing it. After a year you might think you are experienced but you have barely grown in your understanding and it becomes obvious when you try to interview for new jobs. You are lost if you spend any time listening to seniors talk about architecture, testing, and other general best practices. In your future career I imagine you would look back at this time astounded by how little you knew when you thought you knew what was going.

Where iOS bootcamps fail

A couple weeks ago I was asked this question on the ios-developers.io Slack:

Abbey, you mentioned the dev bootcamp in the thread above and I was wondering how useful was that in boosting your career (or kick-starting) it, some of my students in NYC wanted to ditch college for a dev bootcamp. I have mixed opinions about it, I think if you can get a degree and won’t be burying yourself in loans then it should be a no brainer. So as a general thought, has this bootcamp helped your career? Do you think you could have done the same w/o it?

From that question, and my subsequent initial reply, began a really valuable discussion which included myself, some bootcampers currently looking for work, as well as some other really knowledgeable, strong, helpful, and passionate developers who have demonstrated to me their interest in helping new developers since the first day I met them. Their comments warrant full consideration, this is not a case of taking anything with a grain of salt. What follows is a summary of that conversation.

Despite my path, in general I and the others that contributed to this conversation do not recommend quitting university to do a bootcamp, especially if you have already invested time in your degree. But there is no right answer to a question like this. The only right answer is “it depends”.

Specialized Learning

One of the biggest drawbacks to an iOS bootcamp is also one of its biggest strengths. When you do an iOS bootcamp you are not exposed to other programming platforms, you specialize in iOS only. This has an obvious advantage: you don’t waste time learning stuff you won’t use. But it has a less obvious disadvantage which I believe is the crux that has given bootcampers such a bad rap: You don’t have enough far reaching experience to understand what the fuck is actually going on.

Bootcampers can make apps, I don’t think anyone will disagree with that. But this is equivalent to cooking a roast that looks great on the outside and then you cut into it and a big chunk of it is raw because the cook didn’t understand how to deal with the innards properly. They didn’t know the best process to use.

Or maybe a more relatable answer can be found on some of those home disaster style reality shows where the foreman / experienced installer comes in. To you the bathroom looks fine but then he starts explaining everything that is done wrong and to do it properly is going to cost. If the bad contractor were making a bathroom for their own house maybe it wouldn’t matter that eventually the tiles will be crooked or there will be a leak here in this grout, but it just doesn’t fly for a professional company.

They are lacking the foundational knowledge needed to understand the full results of their decisions and this is where bootcamp education fails.

That bad contractor knows how to do things but they don’t understand enough to know how to do things right. They are lacking the foundational knowledge needed to understand the full results of their decisions and this is where bootcamp education fails. This is the kind of thing that can only be achieved when a person fully understands how programming works. When they can intuit what needs to happen rather than just knowing what functions to call.

When iOS stops being magic

For me it was about 6 months of working full time with an incredible mentor who would spend hours each day answering my questions, and then me spending hours each night on Slack asking more questions, before iOS stopped being magic. And I wasn’t just working full time, I had also been writing training documents for new devs at the company, done a presentation on Xcode’s UITest framework after researching it and publishing that research for the team, had been exposed to apps for 3 major companies, two in home security and one in music streaming, had built two apps at work from start to finish, and had done client projects in my free time.

Think about that for a bit and put it into perspective. If it took me all that work for iOS programming to stop being magic, for things to finally click, how long would it take a dev who has been tasked to only UI work and not given the opportunity to be involved in other areas of the company like I was? Even if I am a slow learner and it would take most people half as much to get past iOS being magic, it’s still a lot. Someone with prior exposure to programming, even if it wasn’t iOS, would definitely have an advantage here.

The advantage of a computer science degree

The comp sci grad has been trained over the course of 4 years to research and investigate and to intuit. The bootcamp grad knows only what code to use and if they can’t find the right code they get stuck because they don’t know what else to search for.

While a university degree will not take the magic out of iOS specifically it exposes you to other computer languages, other platforms, and more importantly other people. Just by immersion your understanding of programming will be inherently different than a bootcamp grad’s and this is a significant advantage. For most companies looking to hire a new developer, a university grad is preferable even without iOS experience because the belief is that the computer science grad only needs to learn a new language and platform, they should already know how to think like a developer and understand how code hooks together. The common belief would be that if you make it through a computer science degree you should be easier to teach because you will not be clouded by not understanding what is going on.

From my experience talking to new iOS developers, both from university and from bootcamp I would tend to agree with this. The bootcamp grad appears at first to be ahead. They know frameworks and can generally answer how things work. They tend to write their code in an “iOS way” whereas the comp sci grad’s code can look bizarre for use in iOS. The first few tasks are less frustrating for the mentor with a bootcamp grad than they are with a comp sci grad just starting iOS.

But after the first few, when we expect to see some progress, the bootcamp grad starts to fall behind the comp sci grad. The comp sci grad has been trained over the course of 4 years to research and investigate and to intuit. The bootcamp grad knows only what code to use and if they can’t find the right code they get stuck because they don’t know what else to search for. I still have problems with this but I am getting better.

The great equalizer: knowledge

This is where my answer of “it depends” comes into play. For someone like me doing a bootcamp rather than a computer science degree was the right choice. I am a self starter who is able to see where my knowledge gaps are and fill them on my own by seeking out whatever resources I need in order to accomplish that. A friend of mine left his computer science degree with only one year left because he is the same way and he knew that he wanted to do iOS. He is an enthusiastic learner who didn’t need his diploma to land a permanent job and he already had grasped the understanding needed to be able to learn proper iOS development.

A good mentor who pays attention, understands the way their new developer underling thinks, and provides clear non-judgemental answers, can make the distinction between a university grad and a bootcamp grad irrelevant but good mentors are hard to find. Many new devs whether they are from a bootcamp or a university don’t find a mentor they click with who can provide this.

But increasing knowledge on your own, seeking out answers to questions through forums and Slack groups, can level the playing field.

Not all computer science programs are created equally

One reply to the conversation we were having on the ios-developers.io Slack was:

Note that college programs vary wildly, I have interviewed people who just graduated with CS degrees who had no idea what they are doing, and how much practical software engineering they do can ranged from literally none to a professional amount

An interviewer who knows the platform they are interviewing for will quickly spot those university grads who have made it through their degree without fully grasping the point of their degree. It’s important to keep that in mind: Having a computer science degree does not mean you will get a job in iOS. Generally you still need to show that you have worked on and been interested in iOS.

In the hunt for your first job having a computer science degree can be to your advantage because it gets you that interview. My friend above who did 3 years before leaving university would not have gotten the internship that led to his full time offer if he had not been in university; these kinds of opportunities are rarely handed out to bootcamp grads. This is another disadvantage of a bootcamp: they often are not publicly funded, and often not accredited, which means government job hiring programs do not apply

The great divider: Misinformation

every good developer can learn and a good developer will be a good developer whether they did a university degree or a bootcamp program.

In my opinion, misinformation, or rather ignorance, is the biggest problem with iOS bootcamps. As far as I am concerned every good developer can learn and a good developer will be a good developer whether they did a university degree or a bootcamp program. They will have unique challenges related to their education going forward no matter what education they choose to do. However, the bootcamper (and in here I lump together also people who have learned iOS through online courses with no prior programming experience) has a foundation of ignorance when it comes to their own level of knowledge.

The university grad knows they don’t know stuff. The bootcamper has been told by their school and their instructors – as a way to encourage and build their confidence I assume – that they are programmers, that they can build anything, that they can do any job. In fact the truth is when you graduate an iOS bootcamp (or a computer science program) you are (usually) not a programmer. University grads know this but iOS bootcampers and online students have been told otherwise. It is worth stating again:

when you graduate an iOS bootcamp you are not a programmer

Of course exceptions apply but being able to bake a cake doesn’t make you a baker and it’s the same thing here: being able to build an app does not make you a programmer. When you finish an iOS bootcamp or an online course you are capable of creating. You are a creator and that is a fabulous first step and an incredible skill that most people do not have.

In fact I would wager this skill can make you more valuable than a computer science graduate who has a similar knowledge level because creative thinking is hard to teach and often killed and pounded out of a student in university. But what you have learned in bootcamp is no different than learning any other tool. If someone makes Wordpress, Wix or Squarespace websites using pre-made templates we do not call them a web developer. They may call themselves a web developer but the community at large would vehemently disagree. Simply learning a tool – in this case basic iOS via Xcode – does not a programmer make.

The disadvantage bootcampers face is that they have not been told this. As a way of selling their courses bootcamps and online schools tell would-be students that they will “be” a developer when they finish the program when what they should be telling them instead is this:

When you graduate this program you will have the skills necessary to create iOS apps, and the foundation required to continue learning and build a career as an iOS developer.

This is how I worded it when I answered the university teacher who asked that original question:

Yeah at my bootcamp they were all “you guys can do anything, you’re devs now”. It was irresponsible. Lots of those guys never ended up with iOS jobs. I was deemed the “bad” student [who only completed 40% of my assignments]. Barred from career events for example. Yet my final project won the public demo day and employers wanted to talk to me. I wasn’t the fastest or smartest. I was just fucking realistic…The other students didn’t stop to ask “is this the best way”, they weren’t even aware there could be a better way. They were told they were devs because they made an app. For me, I only completed 40% of my assignments because the final product mattered a lot less to me than exploring the knowledge that went into it.

When it came to learning iOS, the thought process and understanding was more important than finding code online that compiled and completing an assignment. The difference between myself and most of the students in my bootcamp is that I recognized this early on. When it is time to interview for jobs a lot of bootcampers go into those interviews with naiveté. They have been told that they can do anything, that they are developers now, and even though they don’t always feel confident in themselves they try to stand by what their school’s marketing has told them – they are a developer now.

“I don’t know, but I know I can learn it”

Not me. I was the total opposite. Despite being one of the “worst” students in my class, I had confidence to spare. I knew that the things career services were telling us were not right. I knew that the most valuable thing I had to offer was my attitude and my ability to be taught and to learn, not the knowledge I had. I knew that there was only one person in our whole group I would consider a programmer, only one person that really knew what they were doing (and it wasn’t me). I would go into interviews and confidently answer “I don’t know” when asked a question. What made me a desirable candidate was not knowing my stuff, it was my followup: “I don’t know, but I know I can learn it”. I applied for many many jobs and didn’t hear back from most but I had 5 interviews and every one offered me a job except one who lost funding for the project but told me they would have extended an offer if the project had gone ahead.

It’s not because I was so great or knew so much. It’s actually the opposite. It’s because I knew that I didn’t know a whole lot and I proved myself to them to be a motivated learner. I came to them not with the knowledge required to be a programmer but rather with the foundation I needed to become a programmerand I was fully aware of that.

Unfortunately most iOS bootcampers do not have this awareness and I feel this does a great disservice to the students.

The question about how much you can learn

There is no doubt that a few months is not enough time for learning iOS. I don’t know about other platforms but iOS is so intrinsically abstract with so many rules to follow and so many limitations that it is very difficult for even an experienced programmer to pick it up thoroughly in such a short time. That being said, the university grad also does not know iOS at this level and so I don’t feel that this is a bootcamp specific issue.

It’s worth mentioning though because, related to the above section, I feel it does a disservice to the students to not explain to them that they are barely scratching the surface. I’m not sure if university grads realize how much they will need to learn to really understand and know iOS but I do know that I have never met an iOS bootcamper that really grasped the position they were starting out from. Though maybe this is a blessing in disguise; it’s possible I would never have struggled forward if I had known just how far back I was.

False expectations and crushing reality

Bootcamp grads face more challenges than university grads. Not only is getting interviews tough but getting that first job is even tougher. Companies are less likely to take a chance on you and schools bloat their graduation outcomes which leads to prospective students thinking they can just take this course, graduate as a programmer and boom! They get to work as an iOS developer! Not true.

I consider it pretty irresponsible of schools to twist and interpret the outcomes like they do without full disclosure. If you are looking at an outcomes report that says 90% of students get a job within 3 months make sure you ask some important questions:

  1. Are they coding? Are they doing iOS?
  2. Were they hired at a standard starting salary or an internship salary?
  3. How many that were hired at internship salaries got to move up to a standard salary?
  4. Of the ones doing iOS, how many are hired onto teams vs being the only iOS developer?

In my bootcamp almost everyone did get a job in tech and that is important to note, but they didn’t all get jobs doing iOS and they didn’t all get jobs coding. If you really only care about making a career change into tech then this information may not matter to you. Myself if I had not ended up working in iOS I would have considered it a giant waste of time. It all depends on your own personal goals.

At my school most did get jobs within 6 months but I know of a couple who didn’t and I know of several on Slack that took 6-12 months. Being unemployed for 6 months or even a year can be absolutely devastating. A new developer’s confidence is a fragile piece of china, at best. My first year I would break down crying on a regular basis that I would never be able to make it, that I would never understand what was going on – and I had a job! I still get overwhelmedand feel like I am a bad developer even when I am being praised for my work. Programming is hard. It is incredibly taxing on your mind. Being an adult and not knowing what the fuck is going on is really demoralizing. Now imagine feeling like that but also not being able to find work: Absolutely soul crushing.

Bootcampers often get the shit jobs

I have heard more stories of employer abuse from iOS bootcamp grads than I have from comp sci grads. I feel this is probably related to the fact that the university grads are more likely to get a job at an established company whereas the iOS bootcamp grad is more likely to get a job at a start up which has an inexperienced management team.

From what I have witnessed it seems to me also that a larger percentage of iOS bootcamp grads end up at companies where they are the only iOS developer versus computer science grads who end up at companies where they are on a team. The opportunity for mentorship is reduced but the real shame is this kind of first job can actually hold a lot of people back – it can have ramifications that permeate through their career. If I had ended up in a job like this I would not have progressed the way I did.

A new developer working alone is not exposed to best practices, they may continue to learn but they are learning in isolation and any bad habits or non-standard ways of solving solutions will seep through their code. Once these less correct ways of doing things become standard for a developer it is going to be difficult not only for them to change their habits in the future, but for them to even understand why they should be changing their habits. They have essentially wired their brains to think the “wrong” way, they have not learned how to involve others in their decisions or use other people’s experience to inform their own code, and they are difficult to work with and integrate into a new team. The result of this is that sometimes finding that second job for this bootcamper can be tough too.

If a bootcamper has been hired out by it’s school to a start-up where that bootcamper is the only dev on the project, a future company knows that this developer, who now considers themselves an intermediate, could pose more challenges than hiring a brand new university grad with no experience. The bootcamp grad left their iOS school being told they were a programmer. They were hired as the only dev at a start up and they made an app. They know what they are doing, damnit! They lead this project, therefore they are definitely an intermediate developer now and they know how to do stuff.

At least that is the attitude that they have. And who can blame them? Being in that kind of situation you have to have confidence and blind belief in yourself or imposter’s syndrome will eat away at you. It was only a matter of survival. So I get it, I really do. The problem is by the time they go for their next job they usually have lost their humility and they are unable to admit they really don’t know much. This is a hard person to work with and an even harder person to mould into a great developer.

Unfortunately this trend does not only affect the iOS bootcamper described above. Many companies who have hired iOS bootcamp grads in the past for their second job have not had great experiences and this has informed their hiring practices: namely they don’t hire bootcamp grads pretty much in any circumstance until they have proven themselves at a few other companies.

So this means even if you are not that kind of person and you did not go through that experience in your first job, you are dealing with companies that have been burned by hiring bootcamp grads in the past. You have to work harder than that computer science grad to prove that you will be an asset to the team.

This can also be an advantage though because when you find a team lead or manager that is willing to take a chance on a bootcamp grad you know that they are open and willing to not be stuck in traditional ways of thinking. Fact is, you don’t need a university degree to do iOS. I can believe that it is necessary (or extremely helpful at least) in other platforms but iOS is quite specialized and if you know that specialized knowledge you can succeed no matter your education. Personally, I want to work for people that believe it’s more important to hire someone who knows the language and can manipulate data to solve a problem vs someone who can rattle off the definition, and give an example, of O(logn) notation.

Access to information and people

The kinds of people you find at universities and bootcamps vary greatly and each have their own sets of advantages and disadvantages.

The teaching staff at universities tend to be composed of academics and ex-industry professionals. These are people that have worked on real projects for real companies and have experienced different kinds of workflow management, sat in on scrums, learned to balance company priorities with team management and project deadlines. The academics have an intimate understanding of the things they teach though they may not have real world experience in implementing them or integrating them with other components.

The teaching staff at bootcamps on the other hand, tend to be made up of indie developers. I assume this is due to the irregular hours, often part time work, and the pay being less than what an industry dev would earn if they stayed with their full time job. Most of my teachers did not have real world experience aside from their own companies and projects. One may argue that is real experience but when I would ask what was normally done or what was best practice in a given scenario or why they did one thing over the other they usually didn’t have an answer.

This lack of experience in the teachers leaves the students ill-prepared. The teachers themselves don’t even realize what they are not teaching the students because they themselves do not use these words and phrases as part of their everyday vocabulary. I had no idea what scrum meant, what a “ticket” was, what “architecture” meant or even that “api”, “sdk” and “library” all pretty much referred to the same thing. In fact I had absolutely no idea that there were many different architecture patterns you could learn.

Lack of teaching experience but no lack of enthusiasm

Most developers do not have teaching experience aside from mentoring, and why would they? They entered a career as a developer, not a teacher. Teaching staff at universities have to take courses that teach them how to teach, from what I’ve seen bootcamp teachers do not do this. Further because a lot of the teachers at bootcamps tend to be (usually successful) indie devs, they have not worked in big teams where mentorship was part of their duties.

The teaching assistants at my bootcamp were often previous students and it was my experience that other than giving the answer (the right code to type) and despite being great people who really wanted to help, the majority of them didn’t yet have enough experience to know the answers to questions. At university teaching assistants are previous students also but they are usually grad students who have completed the entire 4 year program and have a more advanced understanding of what is going on.

This lack of experience though was made up for by the fact that the bootcamp teachers and teaching assistants tend to be pretty enthusiastic about learning and teaching and iOS in general. I haven’t been to a computer science program so I can’t say for sure but based on my own experiences in university I would guess the staff at a computer science program probably are less enthusiastic and less excited to teach. Indie devs are devs because they think the technology they work with is cool, they have fun, and they are excited to share this enthusiasm with others.

This enthusiasm is infectious. I think it is what got me through my bootcamp because these people were like me! They were curious and excitable and I really identified with that. I think I would probably never have finished a computer science degree, I would have gotten bored.

I would still choose a bootcamp

I know it sounds like I am hating on bootcamps but I’m not at all. Totally the opposite actually. I do still recommend bootcamps I just think people have to be more realistic going in. If all you do is follow the instruction at the bootcamp, complete the assignments by doing tutorials and googling for code snippets, you will never be more than someone who can make stuff. It will be a long time before you are a “real” programmer and you will have a hard time getting into the industry with a proper job.

Programming isn’t something that can be taught in a few months and I’d argue it’s not something that can be taught at all. Someone can provide you with the foundations but whether your brain makes those connections to enable you to think – which is what defines a programmer – or you simply store how to’s in your memory, is up to you.

That’s why I think a new grad from college vs a bootcamp is mostly only different in their ability to understand programming, their potential to find their first job, and their attitude coming out of their program. I think in both cases actually being a programmer can’t be predicted and is up to the individual student. I do think if you are already in a university program you should carefully consider whether you should leave or not because there are important things to think about on both sides of the coin.

During that conversation on Slack, almost everyone could agree that usually finishing your degree will be the right choice. Having a degree will get you easier access to interviews and to industry people who can refer you for interviews. Going through a computer science program will help you understand programming which will be an advantage bootcampers don’t have. But there are many instances where doing a bootcamp is an equally good decision. I never would have been able to change careers otherwise; there is no way I could have taken that much time out of working or afforded tuition.

I also think that if you are a motivated self learner you can skip the university degree. If you work hard you will gain the understanding that a degree gets you on your own and if you demonstrate these kinds of traits well in an interview it won’t matter what your education is. If you can prove that you can do the job and you are willing to put in that extra time to learn and study, the degree is not needed. But what is needed is an understanding that simply doing bootcamp assignments does not launch you into a lucrative career as a programmer no matter what your bootcamp tells you, no matter what successful student they show you as an example for what their students do.

To be perfectly honest I would actually like to do a degree in the future, for the knowledge I could gain from it. I do feel like it would be valuable, but the interesting thing is I don’t think it would have been as valuable as my learning tool. For me doing the degree after working as a developer, where I can apply real world understanding to the courses I take, will result in much deeper learner and bring more value to my career and knowledge levels.


What it’s like to learn fast as a developer

Originally written about six months after joining Intel as a developer. Published May 23, 2017 on LinkedIn: https://www.linkedin.com/pulse/what-its-like-learn-fast-developer-abbey-jackson/

When moving my articles onto this new site I have not edited them except to fix broken links or incorrect information. I like to preserve the original mood, bad grammar and all!


That title doesn’t really role off the tongue but I couldn’t think of anything better. 16 months ago, when I had been working for 5 months, I wrote a very popular article on LinkedIn: What it’s like to be a new developer.

Looking back at that article now I find it interesting. It doesn’t resonate with me anymore. In fact it doesn’t sound like great writing to me either. It’s disjointed and I find it doesn’t express my ideas clearly. But I think that is pretty evident of my state of mind at that time and I think also that it is a state of mind that other new developers share. I believe this because I have received countless private messages on slack and on LinkedIn from new developers telling me how much that article helped them. How they related to every word I wrote. How they were shocked to read these words from their own minds written down by someone else. It helped them feel not so alone. It helped them talk themselves down to realize other people have the same thoughts and experiences.

Now I am past the point of being a new developer. I have only 20months work experience (that’s a little over a year and a half) but I have lead a project, mentored others, done architecture design and am currently on a feature team for an important part of an in-development API that my app will consume. Somehow in that time I found my way to Intel with only 15months experience even though I have no computer science education.

I’m not the smartest…but I genuinely love what I do.

I want to give you some perspective so that you don’t get the wrong impression. I might have made it to Intel quickly but I’m not the smartest. I don’t “get” concepts right away. I definitely don’t remember APIs that I read and I often come across “new” tasks only to remember halfway through “hey wait a minute I actually did this on another app 6 months ago”. I have a horrible memory. I was also one of the worst students in my 8 week bootcamp, only completing 43% of my assignments and failing my midterm exam. But my learning has gone quickly because I genuinely love what I do. Loving what I do means I am curious and passionate, always investigating new things, always interested in my colleagues’ code, always saying yes to challenging tasks. It’s awesome. And it can be tiring. But usually awesome.

The thing is, even though I do these important things at work I still feel like I have no idea what is going on most of the time when I am talking to other people or reading proposed API documentation or product specifications. People talk to me and I hear a word I don’t know, go off in my mind trying to figure out what it means, tune back into the conversation 10s later and have absolutely no clue what they have been talking about since my brain checked out. I sit down in a meeting often not even understanding what the meeting is supposed to be about until the meeting is done.

Other days chug along pretty good. I get my work done and I feel pretty good about myself. I learn a new library, I teach a colleague about the library, I feel confident. And then someone does something in the app that surprises me or I see someone answer a question on ios-developers slack and I think “wow I never would have thought of that, I sure have a long way to go” and all of a sudden I get knocked down a couple notches and my excitement wanes.

It’s not the same as being a new dev. I don’t think I suck. I know I’m a good dev even if I don’t know as much as another dev.

It’s not the same as being a new dev. I don’t think I suck. I know I’m a good dev even if I don’t know as much as another dev; my history and how quickly I’ve gotten here is evidence that I’m a good dev. And I believe deep down that being a good dev is a lot less about what you know and a lot more about what you are capable of doing. But getting knocked down a notch is demotivating. Suddenly my energy is gone. I’m not that excited to tackle the next task. Doing tasks that I am not excited about now becomes a struggle. It’s hard to stay focussed. I want to do something simple. Stuff is hard. Life is hard. I just want to build apps like I did back when I didn’t know what I didn’t know.

But now I do know what I don’t know. And I laugh at myself most days. I think it’s just learning fatigue really. I’m in this strange place where there is still a lot to learn but I haven’t come across a task I couldn’t do without being walked through it for quite some time. But because I haven’t allowed my career to stall, because I am always taking on new tasks (everything from actual development tasks to architecting to project planning) I am always learning. And not just learning little things about a new API but often I’m learning big huge new things. Sometimes I am tired of learning every day. Other days it’s pretty exciting. Some days I am happy to just knock out a simple UI task. Other days those are boring and I want something challenging.

Basically, being a dev who is learning fast means you live your work life in a paradox.

Basically, being a dev who is learning fast means you live your work life in a paradox.

And sometimes you know what? Sometimes I get overwhelmed still and reach a point of paralysis. I think the difference now though is that it doesn’t cripple me. I have tools in my toolbox and I reach into them without allowing myself to be stuck for too long.

It’s important to be humble about what you do and do not know and not be afraid to ask for help. It’s equally important to not judge yourself when you do need to ask for help. In fact, you should only judge yourself if you are not asking for help. Drive and ambition and ego are needed when you want to progress quickly but they can only take you so far, at some point you need to be vulnerable and expose your weaknesses. Humility is the only way to open yourself up for even more growth… Hey, another paradox.

I hate it! No I love it! No it’s too hard I want to quit! No it’s not too hard it’s fun!


What its like to be a new developer

Originally written while working remotely at a large mobile app agency with several offices around the United States. Published January 21, 2016 on LinkedIn: https://www.linkedin.com/pulse/what-its-like-new-developer-abbey-jackson/

When moving my articles onto this new site I have not edited them except to fix broken links or incorrect information. I like to preserve the original mood, bad grammar and all!


So, here I am 10pm on a Wednesday night just sitting down to work. No, I didn’t procrastinate and no, I don’t work overnight, and no I don’t even usually work this late. That’s a lot of don'ts isn’t it?

Here’s some do’s for you: I do work remote and keep regular daytime hours. In fact, I do start work every day at 7:30am. I do work for a great company and I do get some flexibility in my schedule. I do have monthly dentist appointments that basically take over my life for a day because I do have braces to resolve a jaw issue and today was one of those days.

Here are some am’s for you: I am very lucky to be only 6 months into a career and work for such a great company. I am even luckier to be only 3.5 months into employment here and be afforded the luxury of not having to take a day off for these tedious dentist appointments and instead make up the hours at other times during the week. I am a new developer and I am so happy in my new career that I actually ask for work this late even though no one expects me to be working.

Being a new developer is hard and depending on the kind of person you are and if this career really is the right one for you, you might experience things differently than I do, tailored uniquely to you. Some people are simply great at developing. It comes naturally to them, they don’t get worked up when they get stuck, they find it easy to learn, they absorb new feature announcements and trends, they find new tasks simple to figure out, and docs are an annoying but necessary part of their job. That’s not me.

If I get stuck I get overwhelmed and forget everything I know, this is followed by either breaking down completely and needing someone else to essentially guide me through the problem or solve it themselves, or else panicking for 5 hours on a task that should take one. These things happen less and less with each day that passes but I’m sure there will still be critical moments a year from now. My bootcamp was hard, I get focussed on the details which means it’s hard for me to learn overall concepts. I was a graduated programmer working for 2.5 months before I finally started feeling like I was “getting it”. I feel like I am always behind. I often read about features that I think are new only to discover they’ve been around a year or more. When I am confronted with a task implementing a feature I have never done before I feel lost, confused, stupid, overpaid…and did I mention stupid?

I am a new developer who has to work for it. I’m not saying I’m no good, far from it. With only 6 weeks under my belt of learning I made an app that a government organization is considering adopting. I won best app for that one at my school and a month later my team won best project at a hackathon too. I know that I am good at what I do, when I’m doing it. The problem is most of the time I still need a bit of direction from the lead developers at my company or the great devs on Slack in order to get to the do stage unless it is something I have done before. As a developer, most days you are learning something new. In fact, a quick search on Google will pull up dozens of conversations on this very topic. I like this one where the commenter says he spent 85-90% of his time Googling stuff in the beginning and only 10-15% of his time actually coding. Another person in the same thread says if it’s something new some days could have 0% of their time spent on coding.

This is a pretty harsh reality for a Type-A personality like myself that is used to being good at things. Like a typical Type-A I know what I’m good at and don’t “waste” time on the things I’m not good at…but that itself is another article lol

When faced with something new I often freeze for a bit before I wake-the-F-up and come back to life. After that things progress smoothly but before it is torturous. I don’t feel good. I’ve had panic attacks. Yep, full on can’t breathe panic attacks. I attribute a lot of this to my first job where the “senior” dev told the CTO I was “too junior” and he didn’t want to work with any juniors because they slowed him down. That’s a quote. So I’ve got an inferiority complex that I’m working through. Most days I spend at least 10% of the day thinking I’m not good enough and even though my thoughts might emanate from this poor first job experience, I am not the only new dev that feels like this.

Unlike that dev that can learn what they need from docs I have to work hard for my learning. Docs confuse me, I admit it. I have to get more creative when finding resources if I want to learn something and I practice reading docs almost every day. You read that right, I practice reading docs. I know I should be able to find the method I need and understand it’s implementation and know what to do just by looking at docs (most of the time) but I don’t. Finally after 6 months I can usually find the method and often I can also understand what it does, but when it comes to using it in my own code more often than not I’m still lost.

I spend a lot of time reading and for every article I read I right click and open 3 more in new tabs to read after. Every single day I have to look words up. Today it was IDE. Once I read the definition of course I know what that is but the acronym itself? I had to look it up. I don’t have this inherent knowledge that some devs seem to have.

Knowing all this, which dev do you think has more job satisfaction? Myself or that dev that follows along and just gets it?

I’m willing to wager it’s me.

I love my work. I right click and open those links in new tabs because I’m curious. I don’t mind doing my work at 10pm on a day where I’ve literally been on the move 14 hours not because I have to, but because I want to. Because I love developing and don’t want to miss out. Plus I want to show my team how much I appreciate all the help and guidance they give me. I pose questions to rooms full of developers that have nothing to do with active project work because I find my craft intriguing – I don’t want to miss any opportunities to learn and the best learning comes from hearing opposing views from experienced and inexperienced people alike. And I spend an hour writing an article like this one because I am super passionate about being a developer. In fact, I have twice now shared my story with call centre reps so enthusiastically that they have spent an extra 10 min on the phone with me asking questions about how they too can become a developer.

The life of a new developer is rife with frustrations. There are long nights. There are days, whole weeks even, where one feels unworthy of their job. This is a career that is strongly in the grasps of imposter’s syndrome. That’s the reality of it but there are other days where you kick ass, feel on top of the world and unstoppable. Every day is a challenge, it’s never boring and you never stop learning.

I love it.


Working Remote - What no one tells you

Originally written while working remotely at a large mobile app agency with several offices around the United States. Published July 10, 2016 on LinkedIn: https://www.linkedin.com/pulse/working-remote-what-one-tells-you-abbey-jackson/

When moving my articles onto this new site I have not edited them except to fix broken links or incorrect information. I like to preserve the original mood, bad grammar and all!


https://www.pexels.com/photo/person-woman-apple-hotel-5329

My company went from 3 remote workers (I was the third) to around 20 in the time I’ve been there. I have seen people come and I have seen some people go. Remote definitely works, it can be done quite successfully, but is also definitely not for everyone. Working remotely can be really hard if your company is not 100% remote (or even if it is!), especially if you are a newer developer, which is why a lot of remote-friendly companies will only open their remote positions to experienced developers.

Most articles talk about how great working remotely is for both you and the company. Some articles talk about how to make working remote better and even some articles will tell you the best schedule you should be on. No one ever says anything bad about it. Well, I’m here to open your eyes a little because it’s not always a piece of cake.

It’s difficult to integrate into company culture

You’re not there to laugh when someone does something stupid. You don’t get the inside jokes. You don’t get to go bowling with the group, and there are no beers with colleagues in the lunchroom Friday afternoons. Being a part of your company’s social structure takes extra time and extra effort and you will never really be part of the social structure of the on-site workers in the same way as if you were there. If you want to be friends with someone you have to make a concerted effort to ask them one-to-one how their weekend was rather than joining in the group congregated in front of the coffee maker Monday morning.

Communication can be a bitch

Workers in the office are not always as quick with replies as a remote worker needs. You can’t walk up to their desk and tap them on the shoulder, you can’t quickly shout a question across the room. If they leave themselves online when they go on lunch there is no way for you to know they’re gone. If they don’t leave an away message with details there is no way for you to know when they will be back. Of course these things only matter if your company requires everyone to work the same hours. If you are working in a company with variable hours these challenges can be greater but also chances are high that in general the company’s communication style is more asynchronous. In a company like that, rather than working in a scenario where you are expected to be available and thus your workflow expects your colleagues to be available too, your work routine will be such that you expect long delays between communications.

It’s hard to take a break

You tend to work way more than you want to because you don’t have a room full of colleagues leaving for the day making you feel like you should leave too. You work the same place you live so separating work life from home life can be really challenging. There are tons of strategies to help with this, but not everyone can mentally separate themselves from their work. A lot of remote workers work a lot more than 40 hours a week because it’s really hard to sit down and turn on the tv when you know there is just one more thing you need to do on that task. Taking breaks during the day, or at least lunch, is really important to high job satisfaction and low burn out but a lot of remote workers don’t do it. As a remote worker, living in your workplace, you may find you can never stop thinking about work even when you’ve turned the computer off.

You have a skewed view of your performance

You tend to feel like you are not performing enough and therefore like you should work more because you don’t get first hand sight of other’s struggles. This can happen to anyone but is more prominent in newer developers. You are more apt to believe that everyone else is sailing through while you are the only one struggling because you aren’t hearing other people ask each other questions. You don’t get to see anyone else put their head in their hands, smack their keyboard or otherwise breakdown.

Your struggles happen in isolation

If you feel anxiety or imposters syndrome it’s much harder to break out of that paralysis when you are alone. There is no office banter happening behind you to distract you. There is no small talk at breaks except what you can get through chats. Calling someone on a hangout to talk gives things an official feel that doesn’t help when all you need is a light-hearted talk about the stupid shit your neighbour did last night. When you’re in an office this kind of stuff is available in abundance. On your own you need your own tools and strategies for dealing and you don’t get to enlist the unknowing help of others through random interactions. Plus no one is going to notice that you are struggling like they would if they saw you and observed your behaviour. You have to be self responsible and know when you need to reach out to others for real talks and for distractions otherwise you will burn out before long.

Opportunities for feedback are limited

You don’t get constant feedback like you do when you are in an office because even though we don’t realize it a colleague smiling at us is feedback that we are doing good and so you tend to experience anxiety and imposters syndrome more often. With some colleagues your only feedback may be straight up comments on your work. These are meant to help you and your team and they are most likely not meant as a negative but it’s a lot easier to take this stuff personally when you’ve never seen that person smile at you or joke around with you. Even a really confident person can be affected by this lack of interactive feedback though it may be in more subtle ways, for example showing up as lowered job satisfaction.

Maybe you have rock solid confidence, you’re great at separating work from home, and you have so many friends you’re happy to have no familiarity with your coworkers at all - what a relief! Or maybe not. It doesn’t mean you are going to dislike working remotely. Me, I absolutely LOVE working remotely, but I do experience all of these things, every single one.

Working remotely isn’t just about being able to self-motivate - though of course it does take a certain personality type to stick to a schedule - there is a lot more to it that people don’t realize. Sometimes people leave remote positions because they just can’t cope. Maybe they feel left out or they experience anxiety, or maybe they can’t separate work from home. Whatever the reason, working remotely can be pretty tough if you don’t put in the effort to overcome the obstacles. It’s incredibly rewarding though once you figure out your own magic formula!


A Guide to Xcode’s UITest

Originally written in December 2015 and published at: https://blog.metova.com/guide-xcode-ui-test/

Note: This article was written in mid December 2015. At that point UITest was still experiencing several bugs. Many times I had tests fail that the next day would pass after no changes. I have not used UITest since as my current project has a QA team that writes and performs UI and functional tests and so I do not know which if any of the issues I discovered in the “gotchyas” section below are still applicable. When looking at the docset keep in mind that UITest is for both iOS and OSX testing and therefore there may be OSX specific items mentioned (click vs tap for example).

If you find something in this article that is no longer true/relevant please comment or reach out to me somehow and let me know. Thanks!

At the time of writing this article there were no official docs. Apple now provides documentation: https://developer.apple.com/documentation/xctest/user_interface_tests

I have tried to update the links in this article to point to the new documentation however I may have missed some. When moving my articles onto this new site I have not edited them except to fix broken links or incorrect information. I like to preserve the original mood, bad grammar and all!


http://developer.mandarapte.com/files/2013/12/01-Xcode.png

Apple’s new UITest suite has some developers excited, and others disappointed in lost functionality. UITest works differently than the functional testing solutions developers have come to rely on, such as KIF. Instead of giving you access to elements themselves, UITest gives access to proxy elements with minimal parameters to interact with. Learning to separate unit testing and unit based uitesting from functional testing can be a frustrating experience, especially when working with a new framework that still has its own kinks to work out. It is my hope the following guide will help developers form some clarity into the methodology needed when working with UITest.

How It Works

UITest is unique in that it does not use the project code to test, it exists outside the app. UITest instead looks at what is available in the simulator and returns to us instances of XCUIElement based on what it finds, XCUIElement and XCUIApplication are the proxies that are used for this. A button is a XCUIElement of type XCUIElementType.Button (or just .Button), for example. This means you are not able to access ObjC or Swift classes/objects nor their associated properties. You can only access XCUIElement properties. This also means there is no @testable or other such imports as in XCTest.

UITest includes a new Record feature which can be used to record actions and help speed up the writing of tests. Tests can be written without the help of the Record feature, and therefore can be part of test-driven development, however when writing tests after writing the code you are testing it is best to first use Record and then modify the results. This is because it is sometimes difficult to predict how an element will be exposed to UITest until you are more familiar with it. It also helps to identify issues you may have been unaware of such as multiple items with the same identifier.

XCUIApplication is the proxy that is used for testing. It launches a new instance of the app for every test giving you a clean slate to run your test on. As with XCTest there are setup and teardown methods and you can encapsulate common functionality such as writing a function in the test file to clear a text field which you can then call in each subsequent test that is needed. You can also make an extension on XCUIElement to reuse code in any part of the test suite.

XCUIApplication launches and terminates the app (launch and terminate, respectively). You can also pass arguments to the application on launch using launchArgumentsand pass an environment using launchEnvironment. From the header files / docset: “Unlike NSTask, it is legal to modify the environment [and launch arguments] after the application has been launched. These changes will not affect the current launch session, but will take effect the next time the application is launched.”

The XCUITest API

UITest is built on top of the XCTest Framework and includes new additions to the API:

Class Reference:

XCUIApplication, XCUICoordinate, XCUIDevice,

XCUIElement, XCUIElementQuery, XCUIRemote,

XCUISiriService, XCUIScreenshot, XCUIScreen

Protocol Reference:

XCUIElementAttributes, XCUIElementTypeQueryProvider

XCUIScreenshotProviding

Constant (Enum) Reference:

XCUIDevice.Button, XCUIElement.Type, XCUIApplication.State,

XCUIRemote.Button, XCUIUserInterface.SizeClass

Constant (Struct) Reference:

XCUIElement.KeyModifierFlags

Identifying Elements -> XCUIElementQuery

Elements are identified using queries, most often using a combination of identifiers and types. Elements are unique, in order to use an element the query must return one element. Apple has provided several shortcut queries (app.tables returns a XCUIElementQuery of all the tables and app.table["table identifier"] would return the XCUIElement of type .Table with the specified identifier vs the long form which would be app.containingType(.Table, identifier: "table identifier")) and one can use the long form or the short form depending on preference and need. Queries are chained together and variable names can be substituted throughout the chain.

let app = XCUIApplication()
let cellQuery = app.tables.cells
    .containingType(.StaticText, identifier:"String Identifier")

let helpButton = cellQuery.buttons["?"]
    helpButton.tap()

There are often multiple ways to reach an element, for instance a cell with identifier “Purchase Cell” that contains a button “Buy Item” and also a label with identifier “Purchase” could be found several ways and if you use Record you should be presented with a clickable token that allows you to choose which version you would like to use:

let cell = XCUIApplication().tables.cells["Purchase Cell"]

let cell = XCUIApplication().tables.cells
    .containingType(.Button, identifier: "Buy Item")

let cell = XCUIApplication().tables.cells
    .containingType(.StaticText, identifier: "Purchase")

let cell = XCUIApplication().descendantsMatchingType(.Table).element
    .descendantsMatchingType(.Cell).matchingIdentifier("Purchase Cell")

If you were wanting to interact with the label or button rather than the cell you could do the following:

let buyButton = cell.buttons["Buy Item"]

let purchaseLabel = cell.staticTexts["Purchase"]

These are short forms, the long form would be:

let buyButton = cell.childrenMatchingType(.Button, identifier: "Buy Item")

Or if you did not have a way to identify the cell but you could identify the table you can also do this:

let buyButton = table.descendantsMatchingType(.Button, identifier: "Buy Item")

If you had a cell that had two buttons with the same identifier you would need to identify which button you would like by it’s index value. Using Record is recommended as in practice I found the elements were not always at the expected indices. Note elementAtIndex will autocomplete but is already deprecated (as of Dec 2015), use elementBoundByIndex instead.

let button = XCUIApplication().tables.cells["Purchase Cell"]
    .buttons.elementBoundByIndex(1)

This would find the button at index 1 out of all buttons on the cell.

let button = XCUIApplication().tables.cells["Purchase Cell"]
    .buttons["Buy Item"].elementBoundByIndex(1)

This would find the button at index 1 out of all buttons on the cell with identifier “Buy Item”.

If you have only one item of a certain type there is an additional shortcut, element. For example if you have a cell containing one button, that button can be accessed like so:

let button = cellQuery.buttons.element

For element identification there is additionally elementMatchingPredicate(NSPredicate) and elementMatchingType(XCUIElementType, identifier:String?). These are separate from

containingPredicate(NSPredicate) and containingType(XCUIElementType, identifier: String?) which are checking the element for items inside it whereas the elementMatching... options are checking the values on the element itself. Finding the correct element will often include combinations of several query attributes.

If you have difficulty interacting with an element, printing the accessibility hierarchy can help (print(app.debugDescription), and if that doesn’t work here is a tip from shinobicontrols.com:

image Sometimes when you tap on an element while recording, you’ll notice that the code produced doesn’t look quite right. This is usually because the element you are interacting with is not visible to Accessibility. To find out if this is the case, you can use XCode’s Accessibility Inspector. Once it is open, if you hit CMD+F7 and hover over an element with your mouse in the simulator, then you’ll see comprehensive information about the element underneath the cursor. This should give you a clue about why Accessibility can’t find your element.

https://www.shinobicontrols.com/blog/ios9-day-by-day-day2-ui-testing

Sharing Code Between App and UITest Targets

UITest is a completely separate entity from the app itself and therefore can only access UI elements however it may be beneficial to share code between the project and UITest target for writing your tests. To use code from the app target there are two options.

  1. Add the file to Compile Sources (or check off UITest target in member dependencies on the file). Must remember to also compile all files used by this file whether or not the test will use them.
  2. Take the shared code out of the app’s files and into a new file and share that file between the two. This eliminates the need to also compile dependent files.

A good example of when this would be useful is given by Big Nerd Ranch where they show how you can use shared code to check if a to-do item is marked as finished (strikethrough). While we can not access the object’s properties directly we can use shared code to return values that we can use for assertions.

Properties, Attributes, Methods & Queries

Please see either the Apple Documentation for a list of properties, attributes, methods and queries. I have deleted the information I collected about them from this article as I expect things have changed in the two years and it is best to learn about these things from the official docs.

Be aware that UITest uses the accessibility API to populate attributes for the XCUIElement under test.

How-To’s and Gotchyas

This article was originally written in Dec 2015 when UITest was in it’s infancy. I am certain most of these gotchyas will have been addressed by Apple in Xcode updates since that time. If you work with UITest please let me know if any of these are no longer an issue so that I can remove them from this list.

Frames For Off-Screen Elements

Queries will return elements which are offscreen. If the frame is needed for test logic or an assertion, before getting the frame make sure it is on screen, usually by tapping on it first.

Asserting Adjusted Slider Values

adjustToNormalizedSliderPosition does not guarantee accuracy but rather is an estimate. I found setting 0.0 or 1.0 does give 0% and 100% respectively but otherwise it is best to XCTAssertNotEqual to the previous value rather than test the new value.

Inconsistent Test Failures

UITest is still buggy. Scrolling to a cell does not work consistently. In my tests I had it fail 20-30% of the time one day and then on another day not at all. I witnessed the same thing happen to another developer as well. I also experienced tests failing one day and passing the next, with no changes to the code. If you can not figure out why a test is failing I recommend moving onto another task and returning to debug at the end. When you come back you may discover it is a passing test after all.

Record Returns Wrong Element

UITest will sometimes grab an image instead of a button when tapping on a button. I also noticed that UITest prefers to return Static Texts (labels) rather than buttons, this may have to do with the view hierarchy and what element is on top.

Slider Will Not Move

Slider only slides using adjustToNormalizedSliderPosition if it starts at 0. A work around is to use pressForDuration:thenDragToElement and find an element nearby. Remember this may not be accurate unless you are dragging to an element at the extreme beginning (0%) or end (100%)

Multiple Matches Failure with Recorded Code

Sometimes Record does not identify elements correctly and a test will fail due to multiple matches or no matches when Record gives you code indicating there is one unique match. I found the multiple matches error happened most often when there were multiple matches to the query but the other elements were off screen at the time of Recording. The best way around this is to assign a unique identifier or to determine which index the element is at.

Multiple Matches Failure with Recorded or Written Code // How to Wait for Expected Result

Another reason for a multiple matches error is that queries will sometimes not be complete when the test moves onto the next line. A delay should be able to resolve this problem. We tell it to wait for exactly one result (self.count = 1), or wait for an element to exist or not exist (element.exists == true / false) before moving on and give it a timeout value. This is supposed to be fixed for Xcode 7.1.0 however users were again reporting the problem in 7.1.1.

let predicate = NSPredicate(format: "self.count = 1 || element.exists || etc")
_ = self.expectationForPredicate(
        predicate,
        evaluatedWithObject: XCUIApplication().tables,
        handler: nil
    )
self.waitForExpectationsWithTimeout(5.0, handler: nil)

Recorded Code with Special Text/Characters Do Not Compile

Record also may not convert text properly. A button with a unicode identifier was extracted using “\U2192\Ufe0e" which results in a compiler error and had to be manually adjusted to "\u{2192}\u{fe0e}”. Be aware of this for all escaped characters and special texts such as those used in HTML Strings.

Record Fails To Capture Action

Record sometimes fails to capture actions. The best way to deal with this was to tap until an action was recorded, then do the action that you need and if it was recorded edit the test after to remove the unneeded actions. Several times I was not able to record an action for one element but was able to record it for the element next to it and then edit the test code to target the correct element.

Interacting With Elements Currently Off-Screen

You do not need to include scrolling actions to reach an element far down a page. Once the element is identified it can be interacted with no matter if it is on screen or not; the interaction should bring it on screen. When using Record scrolling actions will be recorded however these lines can be deleted from the test once the element itself is identified.

Work Arounds for Accessing Object Properties and States

As you can not access the object’s properties you can not for instance tell if a label is NSString or NSAttributedString (for example to check if text is strikethrough). This is because UITest only uses accessibility attributes and a person using voice-over would not be told text is strikethrough unless it is part of the object’s accessibility traits. Aside from using shared project code (as described above), a work around for this would be to change the item’s accessibilityLabel to be prefixed with “strikethrough” or if in a to-do list “done” would be more descriptive.

Sometimes you need to check that an element’s state has changed. You can achieve this usually by checking element.value before and after an action. If it is a label or image you can use the accessibility attributes to have it treated like a button.

Nested Collection Views

UITest was unable to identify a UICollectionViewCell nested in a UICollectionView nested in a UITableViewCell. I was not able to test if a nested tableView has the same problem. It could see the element in the collectionView cell but not the cell itself so state changes on the cell could not be asserted.

Animations Causing UI Tests to Fail

In several cases, animation may cause the UI tests to fail (for example, waiting for a button to fade in and be clickable). In some cases, you may be able to wait until the button exists, but in some cases, it is better to disable your animations in your UI tests, and instead use unit testing to check for valid animations.

To disable animations in your test, add the following to your app delegate:

if NSProcessInfo.processInfo().environment["animations"] == "0" {
    UIView.setAnimationsEnabled(false)
}

And this to your set up for your UI test:

let app = XCUIApplication()
app.launchEnvironment = ["animations": "0"]
app.launch()

Resources

https://developer.apple.com/videos/play/wwdc2015-406

https://www.bignerdranch.com/blog/ui-testing-in-xcode-7-part-1-ui-testing-gotchas/

https://www.shinobicontrols.com/blog/ios9-day-by-day-day2-ui-testing

http://masilotti.com/ui-testing-xcode-7/

http://masilotti.com/ui-testing-cheat-sheet/

https://medium.com/@larcus94/ui-testing-with-xcode-7-221d16bad276#.7uwbcrfsr






© Abbey Jackson | Theme leinahtan, DESIGNED BY: MISS-YANI