Some more fixes and new stuff

[rupertbates]

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

[mttkay]

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?

[rupertbates]

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