mttkay
Some more fixes and new stuff
Hi Matthias, I've got a few more changes to calculon you may be interested in pulling:
- Change the way that click() is implemented in ListViewAssertion - the previous implementation was failing for me in certain circumstances (unfortunately I can't remember exactly what they were) this implementation works consistently
- Add some more List assertions - I just added a few more generally useful assertions for lists, such as hasHeader(), and also fixed the hasItems(int count) assertion to work correctly when a list has a header or footer (previously these were included in the count)
- Remove the call to super.setup in setup(Intent startingIntent) - this was causing any extras added to the startingIntent to be stripped off, the class still works fine without it.
- Create a new test type CalculonSingleLaunchStoryTest for working with activities which have a launch mode other than normal - previously activities with a launch mode such as singleTop would often just stall while running and never complete, this fixes that
Let me know if you would rather I separated these commits out into different pull requests.
Cheers, Rupert
Rupert, great stuff again, thanks. I think we should check for that one thing I mentioned about list items receiving click events, but apart from that it's good to go.
Would it be easier for you if I grant you commit rights to this repo? Then you don't have to wait for me to pull things back in, since I'm currently not actively working on this project.
Speaking of which. The reason why we're not using Calculon anymore is not because of its own limitations or anything, but because of the limitations and flakiness of the underlying Android instrumentation tests. We had nothing but trouble, and we're switching to all Robolectric now for unit testing. However, Robolectric like instrumentation tests does not have a particularly nice syntax, and hence my idea was to decouple Calculon's DSL from the backend that implements the actions and assertions. That way one could write Calculon tests for both instrumentations and Robolectric tests by simply choosing the desired backend (they're doing the same with Mockito now; they're building a backend for Dalvik, but the syntax will remain identical). Would that be something you'd agree makes sense to have or where you'd even be willing to help out?
Hi Matthias, you're right about the click events for the OnItemClickListener interface they no longer get fired with that change.
I've realised now what the underlying problem is: I never use that interface, I always specify onClick events in xml and with the original implementation of ListViewAssertion.click() these weren't getting fired, the new implementation fixes this but breaks events specified via the interface!
It seems from the tests that I've run that leaving both methods of triggering a click works, ie:
itemView.performClick(); listView.performItemClick(itemView, position, itemView.getId());
I'm slightly worried about edge cases where both the interface method and the xml method are used, but I can't think of a case in which this would be a good idea so it's probably pretty rare.
What are your thoughts?
Rupert
2012/2/2 Matthias Kppler < [email protected]
Rupert, great stuff again, thanks. I think we should check for that one thing I mentioned about list items receiving click events, but apart from that it's good to go.
Would it be easier for you if I grant you commit rights to this repo? Then you don't have to wait for me to pull things back in, since I'm currently not actively working on this project.
Speaking of which. The reason why we're not using Calculon anymore is not because of its own limitations or anything, but because of the limitations and flakiness of the underlying Android instrumentation tests. We had nothing but trouble, and we're switching to all Robolectric now for unit testing. However, Robolectric like instrumentation tests does not have a particularly nice syntax, and hence my idea was to decouple Calculon's DSL from the backend that implements the actions and assertions. That way one could write Calculon tests for both instrumentations and Robolectric tests by simply choosing the desired backend (they're doing the same with Mockito now; they're building a backend for Dalvik, but the syntax will remain identical). Would that be something you'd agree makes sense to have or where you'd even be willing to help out?
Reply to this email directly or view it on GitHub: https://github.com/kaeppler/calculon/pull/3#issuecomment-3774397
Rupert Bates
Lead Android Developer Guardian News and Media
Tel: 020 3353 3315 [email protected]
Please consider the environment before printing this email.
Visit guardian.co.uk - newspaper of the year
www.guardian.co.uk www.observer.co.uk www.guardiannews.com
On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone
To save up to 30% when you subscribe to the Guardian and the Observer
visit www.guardian.co.uk/subscriber
This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.
Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.
Guardian News & Media Limited
A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP
Registered in England Number 908396