iOS Need Full Testing After Updating Swift Syntax?

[loon3y]

Hi,


I was wondering if i need to do a full test after updating swift syntax. I have a B2B app, against my wishes the senior programmer added swift coding.

We have about 10 customers using our App. Every time the Swift Syntax Gets updated i feel the need to do a full test but time just doesn't permit me to do so because i have to fix bugs and add new features before the deadline (tradeshow dates where they would use the app)


Now every time there is an iOS or Xcode update we have to update the Swift Syntax. Is it necessary for me to do a full test or should it be OK?

I'm just afraid that the user won't be able to print, send orders, etc etc. But I'm thinking it SHOULD be ok. To do a full test everytime for every customer is just extremely time consuming and literally wastes days.



Can i get your opinions?

 

[Mascots]

By testing, I assume you mean moving through the application by hand, giving manual attention towards each aspect in order to be sure it works.

If you are, you should take advantage of XCTest and Xcodes new UI (or KIF's) testing tools the next time you run through so you don't have to manually put in work.

At the least, you should be unit testing a majority, if not all, of the components and classes within your application. Unit tests allow you to run functionality in heavily controlled environments to ensure fundamental programming is consistent and working. You can test smaller blocks or higher levels and it helps ensure your code is correctly decoupled as a side benefit.

UI testing allows you to test the overall flow of your app and ensures that everything is working. Basically, when you run a UI test, it launches the simulator or device and presses the buttons to interact with your app and gives you access to elements to check properties in order to ensure everything is placed together properly and actions are occurring as you expect.

While UI testing was introduced and integrated in iOS 9 and Xcode 7, I still suggest KIF because it is much more powerful and backwards compatible (imo, the only thing Xcode has for it is recording).

You can test sections of your app independently or you can run your entire test suite (UI and Unit) to ensure everything is working properly after major updates. I can run through a few hundred different interactions in my app in under 30 minutes.

Edit: to answer the actual question you asked, yes, you should be testing you app before each release regardless of API and language updates because you don't often know if something small you touched here affected something over there. But also no, you shouldn't have to be doing it by hand if you've done it once.

 

[ArtOfWarfare]

You should be running full tests with every change you make.

Also, you don't have to update Xcode every time Apple releases it. I think it's normal to pick a target at the start of your project and stick with it, even as updates occur (not sure - I've never considered stability to be super important. But my understanding is that when you do consider it super important, this is something you do.)

 

[loon3y]

Thanks for the answers all.

I know we should do any test when we update code, but this swift update was just ridiculous. Honestly i was just stressed out and i hope someone would say "I Never did, and I'm fine". For our latest version we changed it back to OBJ-C thank god.

The guy that pushed for the unnecessary swift coding in our current project said "its fine most of it is just adding a "!" or what not and its automatic"



Because of the swift update, if i wanted to just change a splash screen or add a textfield for data entry or link to a column in a database.

I literally have to do a full test with EVERYTIME, because there were cases where some functions didnt work or it crashed after we updated the swift syntax.

we don't have the man power or time to do this. this is why i changed the current version back to OBJ-C, even if things get deprecated, i can compile and update later. It prevented me from making a 1 min change and compile to basically half day- 1 full day.


Was it a good move to change back to OBJ-C? Is there REAL benefit of having swift in our current project?

I kept asking him what was the reason of adding swift coding? Because its giving us too much maintenance that our team couldn't handle (Apps isn't the main product/software of our company). Delaying deadlines for bug fixes, modifications, and halting research and development.


He said "its better because its newer and better technology" but i honestly think thats some horse****, i don't see any benefits of having swift coding there. Please advise if I am wrong. I advised lets use swift for version 2 of our app, but he just implemented anyways and it gave us hell for the past 1 1/2 years.

 

[xStep]

Even if you agree that Swift is 'better technology', that isn't a reason to force it into a project, especially an existing Objective-C project. As you personally found out it can be inconvenient. Management needs to determine when you should begin using Swift and how to go about it. Sure, senior programmers will have the most influence, but the reason of 'new' is non sequitur and without backing up the 'better technology' statement with facts, so is that.

Most discussions I've been in or heard has re-inforced the idea the the programmers should be given some time to learn Swift before writing or maintaining apps written in Swift. That isn't always implemented, so start learning it on your own. This knowledge will at least make it easier to adapt to the compiler and logic issues that come up every time a new version of Xcode messes with your Swift code or exposed new warnings and errors. Swift is the future for Apple software development and yours too if you want to keep developing for Apple OS'.

Now might be a good time to promote test driven development. It could a bigger short term payback than Swift and in the future allow you to easily confirm replacement Swift code is functioning as expected.

Lastly, while developing milestones I suggest your team stay on the same agreed version of Xcode. It's complicated software and adding the always changing Swift puzzle to it is asking for problems that you described. This can help in cases where you have definite delivery dates. I know coders in loser environments who update Xcode mid-milestone and deal with this issues immediately. Coding wise this often isn't that big a deal, but as you mentioned, testing that the code does what is expected is a key issue. Relying on a human being to always get it right can be problematic.

 

[chown33]

I kept asking him what was the reason of adding swift coding? Because its giving us too much maintenance that our team couldn't handle (Apps isn't the main product/software of our company). Delaying deadlines for bug fixes, modifications, and halting research and development.

He said "its better because its newer and better technology" but i honestly think thats some horse****, i don't see any benefits of having swift coding there. Please advise if I am wrong. I advised lets use swift for version 2 of our app, but he just implemented anyways and it gave us hell for the past 1 1/2 years.

You should probably be looking for a new senior engineer, and the sooner the better.

If he can't be reined in and controlled, and work within the parameters defined by management, he's effectively a loose cannon. If he can't do what he's told, even if he disagrees with the rationale for it, you need to move him out of the position he's in, either out the door or into a different position.

He's not saving you time or money if other people spend hours doing something that should only take them minutes to do if he did as he was told. If he were writing unit tests and producing highly reliable code, that might mitigate, but if it's not perfect (and it sounds like it's not), then he's turning into a liability, not an asset.

I say this as an engineer, albeit one who's been self-employed and doing contract gigs for many years. I've seen plenty of screwups by both engineering and by management. But if an engineer can't follow orders, you'll be better off replacing them in the long run.

 

[AxoNeuron]

There's only two real reasons to move an app to Swift.

1. The app could benefit from the slight performance increase. It doesn't really sound like your app is a powerhouse graphics app that needs every last milliwatt the CPU can provide, so switching your app to Swift for this reason is nonsensical.

2. To prepare for the day where Apple drops support for Objective-C. This should be more of a long term move that doesn't happen with a deadline looming nearby. Moving an existing project to Swift should happen in the background while more important issues always get tackled first. It definitely should never be considered high priority at any time in the near future. Apple has been married to Objective-C for a long time, and transitioning to Swift is going to take a long time too.

 

[Mascots]

Eh, against the others dismissal of it, I think the usage of Swift in an iOS app at this point, even if previously written in Objective-C, is totally acceptable. I highly suggest it, have several apps utilizing it, and major upgrades are (in my opinion as well) negligible.

There are a few reasons listed, but others are just the benefits of its syntax to write safer, well constructed code. I hardly find this a rogue programmer other than his lack of knowledge and exploration of the tools provided. Leading to my next larger point:

What isn't acceptable is not confirming that the components written in it are well tested and stable - that can affect any language. Learn the best way to write while in production all you want, but ensure the outcome performs as needed.

You need to Unit Test. For something that is wrong, write a test to confirm that failure, then fix it, then move on. Eventually you'll be able to be certain that everything performs under the hood as expected. As you "full test", you should be writing UI tests so you don't have to ever manually pick through each time. It's very important.

 

[dantastic]

Nevermind the for or againsts Swift etc.
Swift is a fast moving target at the moment. There is an additional cost involved in maintaining a fast moving target.
If you can afford that cost or if there are benefits in Swift which offsets the costs then go for it.

I have only been dipping my toes into Swift. I don't have any project where I can justify using swift yet.

 

[loon3y]

Again thanks for all the advice. Yeah senior engineer is a bit charismatic, I knew from day 1 this was bad and we couldn't handle the maintenance.

But the fact that he had more experience than me, I thought "Hey, it makes absolutely no sense, and common sense dictates we shouldn't do this, but this guy has 20 years experience and he keeps saying "its better because its new technology, and if we don't add swift now we won't ever" (even though i suggested to wait for version 2)


We can't easily convert, everything is spaghetti code. Which is why I'm pushing or Version 2, if we ever get there.