Navigating with browser.get('') question

[flashquartermaster]

Hi @lathonez,

I have been looking at e2e testing with Ionic 2 and I am curious as to how you plan to navigate to a specific page within the app using browser.get() now that routeing is out and the NavController has come in. It has got me a bit stumped, any ideas?

[lathonez]

@flashquartermaster thanks for the question. I can't really think about this until I've got rc0 done (working on it now).

Will try to think of something when it comes up in the testing phase of rc0..

[flashquartermaster]

@lathonez Ok, thanks, good luck with rc0

[lathonez]

So I didn't have to change anything drastic in the migration to rc1. I didn't actually write the e2e tests in the first place, but none of ours were are using the router to navigate.

We switch between pages by browsing the app as a user would (invoking the menu):

https://github.com/lathonez/clicker/blob/master/e2e/page2.e2e-spec.ts#L11-L21

Whilst I'm more clued up on unit testing than I am on e2e, I get the feeling that the "correct" way of doing this would be to browse around the app (could be very wrong there). My point is that it the user can't invoke a transition by clicking something, then how is it relevant to test it?

I appreciate that this doesn't answer your question, but I can't offer more help I'm afraid.

If you have managed to find a solution (or just have gained a little more insight in the meantime), please let us know so it can help others.

Thanks!

[flashquartermaster]

Many thanks for getting back to me.

Yes, I take your point about simulating user behaviours in e2e but there is still an issue with integration testing which might involve starting from a different point in the app.

Imagine you are testing your settings page and the effect changing a setting has on a different part of your app from the integration point of view. You will need to go through the process of resetting the app state and going through all the motions from the start page to get to the point in the app that you want to test. This slows your tests down and could make the tests more brittle, increasing your test code maintenance as the user flow through the UI alters (as it will inevitably will).

There may be a way around this, but I'm just not sure what it is.\

It all depends on whether you're happy mocking things and leaving it at that or if you want to simulate user interactions as part of the integrations.

I'm sure you appreciate from unit testing that the point is to be able to swap production code in and out without the tests changing in order to have confidence in your system. Increase test code maintenance and you will start to reduce the confidence the system because the test code has to keep changing with the application changes.

Because of this, I have started to move over to NativeScript since it uses Angular 2 routeing which will allow me to do fast integration testing.

You might be interested in this. NativeScript has unit and e2e testing out of the box, everything you need is downloaded and installed with examples using the commands tns test init and tns install appium. All you do is specify your framework e.g. Jasmin (although the last time a looked the e2e was only using Mocha, I'm not sure if it has moved on since then).

[lathonez]

This slows your tests down and could make the tests more brittle, increasing your test code maintenance as the user flow through the UI alters (as it will inevitably will).

Indeed, point taken.

Thanks for the reference to NativeScript. We are considering moving off Ionic for various reasons, the seeming lack of real world integration testing adds another. We have a huge closed source project (for which we've yet to implement e2e) and we will definitely run into these issues down the line.

[flashquartermaster]

Just as a heads-up, NativeScript is great once it is up and running, I wanted to do the quick set up to check it out but I found the install process had a number of pitfalls and it took a few goes to get it right. Here is an excerpt from a blog post I was going to do on the subject (unedited so a bit garbled):

I thought it would be easy, having already installed Java, Xcode, Android Studio + SDK and HomeBrew but the installer could not find my Android SDK and I had issues with my version of Ruby. As a result xcodeproj and cocoapods ruby gems did not install so I had to grab a new version of Ruby, but my problems with cocoapods did not end there. I ended up running the installer script a couple of times and having to muck around with the ANDROID_HOME environment variable afterwards, even then I could not verify that cocoapods was configured correctly even though iOS can be built and runs OK. So I turned to the advanced setup but still could not get cocoapods verified and ended up editing the NativeScript config file to not use sandbox-exec.

Additionally, after much faffing about with typescript compiler problems when setting up Protractor as my runner I found this video that made me realise how much time I had wasted setting up e2e testing in this way https://www.youtube.com/watch?v=tu5h2NxTzIo.

I hope that helps.

[lathonez]

Thank you so much for this. Messages like this are exactly the reason that I maintain this project.

[flashquartermaster]

You're welcome, good luck.

[masimplo]

Sorry if this completely off topic, but it is not often I get the chance to discuss similar situations.

We are considering moving off Ionic for various reasons, the seeming lack of real world integration testing adds another.

Could you please elaborate a bit on this? We are in the same situation, we have a huge codebase and are not 100% happy as is, plus moving to NS seems like a manageable task that has mainly advantages to offer. For now we have decided it is better to stick with "the devil you know" but want to evaluate future options.

[lathonez]

It's actually a bit hard to quantify, I've been 95% happy we chose Angular 2 at such an early stage. Sure they made some pretty big changes late in the day (forms, modules), but these changes were definitely for the better so you just have to bite the bullet.

I can't say the same about Ionic. For me rc0 was a big disappointment. Yet another build process, still no testing support. Moreover, I feel some of the challenges we've faced / are facing on our project are "out of Ionic's depth" in terms of community support. For most of these we're able to turn to ng2, but not always (this issue is a perfect example).

For now we have decided it is better to stick with "the devil you know" but want to evaluate future options.

I had pretty much this exact conversation with my CTO today. We're probably in a slightly different situation to you guys as we've not taken rc0 yet (I'm just looking at it now), so we're trying to decide whether to switch onto NS (or another?) instead of doing the huge upgrade and still being on Ionic.

"The devil you know" still won out, for better or worse. I am extremely keen to evaluate alternatives and experiences around migration paths.

Have you spent much time looking at NS vs Ionic (or anything else vs Ionic for that matter)? We have only very recently started discussing this as a serious option.

[ghost]

The lack of testing support/docs on Ionic 2 release process is making it harder to keep all things up-to-date.

Also I think I've read that Ionic 2 will also use Angular Router at some point so it'll be easier to make a PWA/Ionic2 app at some point.

[masimplo]

I completely agree with you on your points about Angular2. It still feels like a great choice even after adopting it at such an early stage and although there have been many breaking changes until now, almost all of the felt being on the right path.

RC0 brought us to our knees. We have been migrating the project for over 2 weeks now and still are not quite there. There have been changes to so many different things that it just hurts to try to think about them as a whole, but the worst thing is that we are still not done, as they keep changing their mind on the build process and we have to follow on a daily basis since we are in a hurry to close this and get on with our tasks. I am not saying that where they are getting at is not right, just that it is a very bumpy ride until we get there.
Also our project feels quite big for what the ionic team is focussing on and feel on our own on some matters.

We have been reviewing NS since it came out at certain points in time, but when we mapped down what had to be done for RC0, we took a much closer look at it especially since the biggest drive for moving to RC0 for us was performance and NS promises native like performance.
On the good side since our app has a lot of "backend" logic and not so much UI related peculiarities, most of our code will be untouched by that transition. We still get Angular2, rxjs, immutablejs etc so our services will be the same. Also tests use the same engine and framework so this is great. All the native plugins that we use are provided in the NS world and other than that they use promises over observables that we are currently using (can be easily wrapped) are pretty much the same in functionality and usage.
The bad side is that we have a pretty big custom plugin that we are maintaining the code for. This will have to be migrated to the "write javascript to run as java or obj-c" approach that NS takes. Also we will have to migrate from using Ionic's routing to angular2 router, which does sound like a step forward as we have had various issues with navigation in the past and still not totally there. And then on to the big job. We have to migrate 100+ templates (pages + components) from html+css to NS proprietary xml templates and css like formatting. Most of the component code remains the same, but 1st it is a large task because of the volume of changes and 2nd it has a steep learning curve what components to use, how to use them, workaround possible bugs etc. Good thing is that I found 1to1 relation for most of ionics components, so we won't be missing any part of our ui implementation. The layout options over at NS seem pretty thorough too and cover most of our current cases. It also opens up new possibilities since you can rely on 3rd party UI components (telerik even already sells some).

Closing I just want to say that NS feels like a better option all-around for our specific needs and it does make sense to say that we will probably be migrating there at some point, just not sure when this is going to be. Ionic still feels like a great product and I am sure it will be much better once it reaches final, facing breaking changes fatigue made us look elsewhere, where thinks look prettier at the moment. Let's not forget we are all pioneers, using a very controversial stack of technologies to do what was almost impossible a couple years back and we have to pay a certain price for that.

[masimplo]

btw @flashquartermaster the DeepLinker might be promising for what you are trying to do. It was introduced in RC1.

[flashquartermaster]

@masimakopoulos Thanks, I gave it a go a while back but it did not do the job I wanted it to

[lathonez]

#191