When moving a service that gathers data from a 3rd party system to a hosted non-GUI system (e.g., AWS EC2) you may need to enable access to the 3rd party system from that non-GUI system by responding to a CAPTCHA challenge.
Problem
The problem is that your 3rd party service provider will recognize attempts to log into your account from a new location and may protect your account by presenting a CAPTCHA challenge.
CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”. Common challenges are images containing blurry letters which can be read by humans but cannot be extracted by today’s image processing algorithms. So there is no way of scripting a response to the challenge. Human interaction is required at some point.
If the shell is all you can use, you can of course access the login page of your 3rd party system, e.g., using wget, but remember that each login request will get a new challenge and will only be granted if the response to the challenge is the right one. So you’ll better use a text browser but then you will still be unable to view the image that you’re supposed to decipher.
Solution
Lynx can be configured to use an external image viewer by editing lynx.cfg. If you don’t find lynx.cfg on your system, just create your own (or download one) and pass it to lynx using the -cfg command line option. On our system, the image viewer xv was configured:
XLOADIMAGE_COMMAND:xv %s
The trick is now to replace xv with a command line tool that helps you to finally see the image. I used scp (using SSH public key authentication) to copy the image file to my local machine so that I was able to use my favorite image viewer to read the text.
You could also print the image or email it to someone who will then read the image’s text aloud when you call him. Anyway, once you got the image to another device, you’re nearly done.
Conclusion
Lynx and scp can be combined to help you to respond to CAPTCHA challenges. The approach outlined here works for graphical challenges but can also be used for auditive challenges as long as there’s any chance to download the audio file or to capture the stream.
This is a response to a blog post by Matt Wynne: Death to sleeps! (2013-06-03). It is actually a great summary of problems we observed in our automated Selenium-WebDriver Tests and I do not get tired repeating the great BDD-step which Matt also observed: “And I wait for 3 seconds” – yes, I found that one many times!
The solution we have found is Java-based and derived from the ExpectedCondition and its factory ExpectedConditions available in Selenium WebDriver. But we were in need of a much broader approach as we not only wait for WebElement’s to appear but also for documents indexed in the search-engine. So let’s extend Matt’s example:
Given I am on the google homepage And Wikipedia Page for Matt Damon is indexed // inserted When I type "matt" into the search box Then I should see a list of results And the wikipedia page for Matt Damon should be the top result
with And Wikipedia Page for Matt Damon is indexed implemented like:
googleWrapper.indexed(matt).waitUntilTrue();
assuming that we have direct access to the search engine and the step Then I should see a list of results implemented like:
resultPage.getList().visible().waitUntilTrue(); resultPage.getList().length().assertThat(greaterThan(0));
where resultPage and the returned list are wrapper objects for UI-elements and length() and visible() return what we call a condition.
The general concept can be found in this outline:
Actually we have three responsibilities in this pattern:
- Expression: knows how to query the System Under Test (SUT) for a certain value
- Matcher: (see Hamcrest) will decide if a returned value matches expectations or not
- Condition: is responsible for repeating the whole process and eventually end with a timeout if expectations were not met in time
Having the conditions we were also able to identify and fix another problem: If we poll the SUT too often it might not even been able to process its update loops. We observed these for search-machines which we polled to often. Olaf Kummer described this problem and the solution in Haste makes waste.
Important about the whole concept of Expression and Condition was a clear contract how the Expression could send a signal to the condition if it assumes that a re-evaluation will lead to a better result or not. So we identified three termination paths illustrated here:
So the Expression might end in three ways:
- returning a value: the Condition will ask the Matcher if this is what we waited for
- ExpressionEvaluationException: the contract says that this signals that the Expression expects that a second query might be successful; this for example wraps ElementNotFound-Exceptions.
- any other Exception: will tell the Condition to not ask again; a severe error got observed
And the Condition also might end in three ways:
- Timeout: the value did not match in a given time or we always only get the ExpressionEvaluationException
- Exception: any other exception raised by the Expression
- Matched: signals that the assertion (in JUnit-context) passed
Experience shows that this approach got well accepted by our developers and Thread.sleeps() are gone nowadays – especially since we also solved the problem how to wait for “something not to happen” like “the error dialog should not pop up”. If you are interested in this approach read on here: The Calm after the Storm – also by Olaf Kummer.
I presented our solution on the XP-Days 2012 in a session “UI-Tests which are fun”. Find the slides (in German though) in my blogpost from November last year.
If you are interested in the implementation you can find it in Joala on GitHub, more specifically in the conditions-module.
In this blog post you will find a convenient batch-script to install (and update) Selenium WebDriver Server as Windows Service using NSSM – the Non-Sucking Service Manager, tested with Windows 7 64bit.
Actually searching through the internet you will find quite many postings on how to install Selenium Server as Windows Service. Most of them either refer to the Windows Server 2003 Resource Kit Tools and srvany.exe or to AlwaysUp from Core Technologies Consulting.
srvany.exe is quite obviously a hack – and from what I have read won’t work with 64bit systems. AlwaysUp seems to have a nice UI and feature like email alerts in case of problems. Nevertheless you have to purchase licenses to run AlwaysUp.
So we found a solution which uses a free tool: NSSM – the Non-Sucking Service Manager. And in order to have an easy update process for Selenium Server I wrote a Batch Script, which basically performs these steps:
- Stop any possibly still running Selenium Server Service (sc),
- remove the service (nssm),
- install the new Selenium Server as service (nssm),
- configure the service to interact with the Desktop (sc) and
- start the service (sc).
The interesting part are actually the version numbers you set at the top of the script. Having them it is a piece of cake to update to a new Selenium Server version – which is a good thing due to their frequent updates.
Below you will find the stripped version of the batch-file. The full version with some convenience checks can be downloaded as Gist from GitHub.
@echo off set SERVER_VERSION=2.32.0 set IESERVER_VERSION=2.32.3 set DOWNLOADS_FOLDER=%HOME%\Downloads set SERVICE_NAME=Selenium Server set NSSM=C:\nssm-2.16\nssm-2.16\win64\nssm.exe set JAVA=%ProgramFiles%\Java\jre7\bin\java.exe set SERVER_BASENAME=selenium-server-standalone set IESERVER_BASENAME=IEDriverServer_Win32 set SERVER_JAR=%DOWNLOADS_FOLDER%\%SERVER_BASENAME%-%SERVER_VERSION%.jar set IESERVER_EXEC=%DOWNLOADS_FOLDER%\%IESERVER_BASENAME%_%IESERVER_VERSION%\IEDriverServer.exe sc stop "%SERVICE_NAME%" >NUL 2>NUL "%NSSM%" remove "%SERVICE_NAME%" confirm > NUL 2>NUL "%NSSM%" install "%SERVICE_NAME%" "%JAVA%" -jar ""%SERVER_JAR%"" -Dwebdriver.ie.driver=""%IESERVER_EXEC%"" -timeout 120 -browserTimeout 120 if not errorlevel 1 ( sc config "%SERVICE_NAME%" type= own type= interact sc start "%SERVICE_NAME%" )
See Also
- Gist nssmSeleniumInstall.bat
- NSSM – the Non-Sucking Service Manager
- coretechnologies.com: How to Run Selenium Remote Control (RC) Server as a Windows Service with AlwaysUp
- coldfusion10.com: Adding selenium-rc as a Windows service
Most modern Rich Internet Applications (RIA) are composed of reusable UI components which are organized in a component hierarchy. The state of a component depends on its place in the hierarchy. So the context of a component has to be propagated down the hierarchy, often passing numerous levels. In a customizable and dynamically pluggable application, it can be a challenge to propagate these values in an equally dynamic way.
Problem
We describe the problem based on a real life product, the CoreMedia Studio. The Studio is a RIA to create and edit content for the CoreMedia CMS. It is a hierarchical and component based application based on Ext JS. Many of the Studio’s components are reusable and they can be used in multiple contexts. To make the context propagation more challenging, the Studio provides a public API to plug custom components into the component hierarchy at runtime. While this adds a huge amount of flexibility to the application, it makes the context propagation more difficult.
So far context information was wired explicitly between a parent and its child components at compile time. While at first glance this might look like a suitable approach, it comes with two major drawbacks:
- This approach only works for child components that are known at compile time. Unfortunately, as stated above, it is part of the Studio’s nature to be customized and extended at runtime.
- When context information has to be propagated over multiple levels in the component hierarchy, each intermediate component has to forward the information to its children explicitly. This produces plenty of boilerplate, error-prone code.
Solution
To address the aforementioned challenges, a solution has to shift the context propagation and wiring from compile time to run time and to pull the implementation out of the component’s code. Both these requirements should sound familiar to a software developer as there is a well known technique to meet them: Inversion of control (IoC).
The idea of our IoC flavour is that some components in the component hierarchy (providers) can provide named context information while others (consumers) can ask to get certain context information injected. A central context manager then uses the component hierarchy to decide at run time which provided values have to be injected into which consumers. While there is no suitable IoC framework out there that is working on a component hierarchy, two ingredients enabled us to write our own framework:
- The life cycle of Ext JS components is managed by a central registry and we have full access to the component hierarchy.
- ActionScript which is the source language of the CoreMedia Studio (compiled to JavaScript) supports annotations.
Implementation
The idea of Component IoC is originally caused by the question how the public-API of the content-related actions in CoreMedia Studio should be designed.
Assume that the providedContentProperty is the name of the content context provided by the parent container of a content action. Then the content action class declares now itself as a context consumer using annotation at the setter method of the content property:
[InjectFromExtParent(variable=’providedContentProperty’)]
public function setContents(contents:Array):void {
...
}
The content configuration is no longer passed statically from the container down to the action. Instead the context manager recognizes the provider and consumer of the provided context at run time and establishes a dependency between them.
Conclusion
Component IoC enables us to avoid boilerplate codes and we use the framework to design a clear, dynamic extensions API for content actions.
However it can be used to unwire the static configuration of other Studio components. Maybe this post encourages you to define your own context consumer or even context provider. Let us know.
As agile coach, you want to keep retrospectives interesting and not just always repeat the same old “mad/sad/glad” or “plus/delta” routine. You might already have visited the Retr-O-Mat or the Retrospective Wiki. Here is another method to spice up your retrospectives during the “gathering data” stage.
- Give the team two questions to answer: “What happened as expected?” and “What surprised me?”
- The team answers the questions on index cards, as many as they like. In turn, they each present their cards to the others.
- Next, you can move on to something like clustering and dot voting to decide on an agenda for the remaining time of the retrospective.
The required time is about the same as for related questions like speedboat, plus/delta, etc.
This question comes in handy for me whenever a team’s real sprint diverges substantially from the original planning and/or commitment, or when I want to prod the team towards talking about interruptions and digressions. Also, I sometimes need to ask “Why did we fail the sprint?”, but these two questions sound so much more constructive.
As a variant, you could use this method for the “set the stage” phase, this time restricting the number of answers to one card per question and participant.
A couple of weeks ago, CoreMedia was seeking internal applications for an employee exchange program with etracker. The two companies had the idea to learn from each other by swapping a software developer for three weeks and offering insights to their culture, processes and software (see ‘Get Insights from Outside the Box’ and ‘Get more Insights from Outside the Box’).
My Motivation
The moment I heard about the experiment I wanted to participate. I thought it was a great opportunity to see another company, meet new colleagues and learn about another product and it’s technology stack. I was also keen to see how another company lives the idea of agile software development and how their way differed from the CoreMedia one.
The Exchange – A Personal Perspective
From the first day at etracker, I experienced my new temporary home as a very welcoming and professional environment with very competent and open minded colleagues. It turned out that the technology stacks of the two companies overlapped in so many areas that I could integrate into the new workplace smoothly. I could dive into the unknown product quickly and got the chance to participate in discussions and design decisions.
Despite the similarities in the technology world, it soon became clear how different the organisation of the two companies is. While both development departments do agile software development, some of their constraints and key approaches were fundamentally different:
Product: While CoreMedia is a product development company, etracker sells a software as a service. This has implications for the desired release cycles and the possible feedback roundtrips in the two companies.
Teams: While each CoreMedia development team is responsible for certain components, the etracker teams are set up in a cross-functional way. Each team is set up in a way that enables it to work at every component.
Process: While the CoreMedia development is organised in a scrummy flavour, etracker uses a Kanban style process.
To see and experience these differences was one of my personal highlights of the experiment. It was enlightening to learn why etracker had replaced their scrum process with the cross-functional Kanban approach as some of the problems they tried to tackle were very similar to the ones that CoreMedia is still facing. It was also interesting to see which of these problems were solved by their move and which ones they got in exchange.
Three weeks of exchange seems to be a pretty perfect duration. It gives enough time to pick up all the details and to get into some kind of a routine in the exchange company while it is still a comfortable time to be away from ‘home’.
For the whole time of the exchange we established a series of open fishbowl sessions where all the etracker and CoreMedia employees were given the chance to ask questions about the exchange and the other company’s organisation. I experienced these meetings as very productive, many interesting questions emerged from the lively discussions.
Conclusion
Personally for me, I think the employee exchange was a full success. I really enjoyed the time and it absolutely widened my personal background. While the completely different constraints and approaches of the two companies make it very difficult to cherry-pick individual aspects from one company and adapt them for the other, it was definitely one of the highlights to see and to ‘live’ these differences.
I would not hesitate to participate in another employee exchange program if I got ever offered the opportunity again.
Last week I reported about our employee exchange experiment. Since then we had many more scheduled and impromptu discussions. Everybody was happy to exchange information on differences and similarities between both companies. Major topics were
- Collaboration
- Cross-functional Teams vs. Component Teams
- Kanban vs. Scrum
- Roles (Agile Coach, Product Manager, Product Owner)
- Work environment (rooms, kicker, coffee, beer, …)
After three weeks the experiment ended, with mixed feelings on our side. We were reluctant to say farewell to our guest, who was already integrated very well into the team and had enhanced the team’s skills. On the other hand, we were happy to see “our” developer returning from the other company after an overall very successful experiment.
Learnings
We have learned a lot. Probably the most important insight is that there is no silver bullet. There are many differences in the ways developers work at etracker and at CoreMedia, respectively, and each approach has its own pros and cons. We have not identified methods or best practices to adopt directly, but we have been challenged to think outside the box and to question our approaches.
Three weeks of exchange seems to be a good duration, striking a balance between cost and insights. More time would probably not result in further significant learnings for our companies, whereas the exchange needed that much time for a detailed insight.
As a side effect, we established an experience exchange channel. Whenever we are facing a challenge or prepare an organizational change, we may now ask our colleagues how they are handling this kind of issue or what their recommendation is.
Last but not least, both developers appreciate having participated and have improved their personal background a lot.
Conclusion
The experiment was very successful. We did not face any trouble. Instead, we learned a lot and want to extend it:
- Repeat it with different engineers to enrich personal skills and experience
- Invite other companies to participate
- Think about exchanges for other roles like Agile Coaches, IT staff, …
- Focus on different topics like technology or innovation processes
What do you think? Have you ever tried an employee exchange, or do you want to do one with us? Please let us know!
CoreMedia AG and etracker have the idea to learn from each other how the processes in software engineering are performed, what differences in culture and team work can be found and much more. We want to generate insights to see the pros and cons of different approaches. Typically you only get this information when people are changing their job. But then they are gone, they are no longer available for questioning. Also employees have to leave to broaden their experience. So why shouldn’t we be able to organize such an information and experience exchange where everybody is a winner and no one loses?
Last week we started an exciting experiment. Let’s imagine, you switch the working place with somebody else for a limited period of time. Working in another company for some weeks, gaining new experience with no risks, knowing you will return after a while to our well-known and loved working environment. Sounds unrealistic, like a dream?
But it is not. Of course, there are many impediments before such a project may start. First of all some legal aspects have to be clarified. For example: What about the risks of sharing intellectual properties? What if an employee likes the intermediate job much more than his regular one and wants to change permanently? What if the exchange program will be misused as a recruiting opportunity? What about health care in case of an accident?
It took some efforts but finally we found a way to handle all these aspects in contracts between the two companies involved.
After all these preconditions were fulfilled, we were able to start the project. We made an announcement that we are looking for candidates to participate in an exchange program. Experienced developers who have been working with us for at least two years were asked to submit an application. Finally we selected one candidate from each company and after a kick-off meeting we started the experiment.
Currently, a software engineer from etracker is replacing our engineer for three weeks. She joins the team and is encouraged to participate as much as possible in regular team work. As we are practicing pair programming and the technology stack is similar it took just a few hours to enable her to bring in her skills in an effective way. She is participating in our scrum meetings and already made her first commits to our repositories.
We will continue to report our experiences.
Keeping time sheets up to date is one of the least favorite activities of software developers. The reasons for this are manifold but the bad user experience of most time tracking tools is definitely a part of the story.
In his blog post “Why Time Sheets are Lame! “, Jeff Sutherland lists several reasons why time sheets in general make no sense. For legal and accounting reasons, many companies need to keep track of the time spent by their employees. In most cases, the timekeeping is done on an individual basis.
In an agile environment, the problem is not the tracking itself but that it is done on an individual level. We are using Scrum which puts the team into the focus and not the individual team member. At the beginning of the sprint, the development team commits itself (or, as described in the newer scrum guide, “forecasts”) to the sprint goal. Consequently, at the end of a sprint, the success of the team is being measured and not success of individuals.
A company should only be interested in the amount of time spent on a certain type of work (e.g., maintenance, development of new features, infrastructure management, …), as it translates directly into the overall amount of cash invested in the topic.
That is why we decided to try time tracking on the team level only. It is up to the teams to choose the right tool for the job (e.g., simple tally sheets, a software solution, just an Excel sheet …). The only requirement is that the sum of the efforts spent on the types of work has to be sent to our controlling department at the end of a sprint. In order to have more fun and because of its practicality, some of our teams decided to use Lego bricks for time tracking. As a result, our time “tracking sheet” looks like this:
Each developer receives the same number of Lego bricks, according to the length of the sprint. The team of which the photo of the “tracking sheet” above has been taken applies a granularity of one brick per half day.
A big base plate is glued to the wall near the exit of the team room. Attached to the plate are Post-its designating the different types of tasks, e.g., work on feature A, work on feature B, maintenance, infrastructure, consulting/support. We use flat tiles to attach the Post-its safely. At the end of a day (or before lunch), each developer places their two bricks for the day on the plate. At sprint end, the product owner counts the bricks by category and reports the hours electronically.
We have been doing this kind of time tracking for a number of sprints now. So far, the results show the approach to be useful and pragmatic to keep track how much time is spent on which type of task. The advantages are:
- The acceptance rate among the developers is much higher than before.
- Time tracking actually happens during the sprint, not months later after individual reminders.
- The developers have the feeling that this lightweight solution helps them to spend less time on time tracking than before (when they had to use an actually unusable software solution).
- By using Lego bricks the whole process has a playful note which helps to motivate all persons involved.
- Collecting the bricks visibly in the team room is part of an informative workplace and gives instant feedback how the team spends (or wastes) time during each sprint.
- The data can also be valuable input for the retrospective.
We are interested in your opinion to this approach of time tracking. Will you try it as well? Do you know others that have a similar approach? Please leave a comment!
Yesterday the Softwerkskammer Hamburg (Xing, Meetup), a group dedicated to Software Craftsmanship, had its March-Meetup. I joined a session titled “Test Pyramid” and we had an interesting discussion on the value of different levels of testing. You will find some thoughts collected from that session in this post.
Test Pyramid
The test pyramid got introduced by Mike Cohn (see for example The Forgotten Layer of the Test Automation Pyramid). It basically states that you have different levels of automated test approaches (Unit, Integration, UI) with increasing costs regarding implementation and maintenance of tests. Thus a UI test is hard to write and very often brittle – not necessarily because the UI changes (it is possible to write UI tests quite robust to UI changes) but because of dealing with asynchronous events and infrastructure problems such as UI machines having a resolution which is too low for testing.
Thus the Test Pyramid favors to have a broad set of unit tests: they are fast, easy to write and – that’s the assumption – easy to maintain.
Unit Tests – the Silver Bullet?
This is where the discussion actually started. Are Unit Tests really the Silver Bullet to develop well crafted software? Experiences reported:
- I had high coverage – but when I refactored it resulted in high costs in also adopting the tests.
- I spent hours on mocking.
Actually what I once learned about testing:
A test is always also a specification.
What’s the point of this? You should be aware that if you write a test you also fixate the code under test. Thus if you test with high code coverage you actually fixate the actual implementation thus as a loop within your code, or ensuring that you visit every branch of an if-statement.
Is this really what you want to do? The advantage is that you can easily add a measurement to those tests (Code Coverage) so you might get a feeling when your tests are sufficient. The disadvantage: You become less agile.
Lowering TCO of Tests
The main discussion was about how to lower the Total Cost of Ownership (TCO) of tests. The experiences reported in the session has shown one observed effect:
While Unit Tests are most likely to break on refactoring, acceptance tests won’t break as easy.
This is actually what Jakub Holy mentioned in his post Principles for Creating Maintainable and Evolvable Tests (I really recommend reading it!). He focuses on “tests that tell a story" – so actually acceptance tests. The (well-written) story will survive longer than the implementation details.
Acceptance Tests with plain JUnit and Gherkin
One approach I reported was using plain Java tooling to write tests as living documentation, tests which tell a story. While Cucumber and JBehave rely on parsed text documents we started to write the stories and scenarios with plain Java classes. The advantage: We have high IDE support on refactoring and good reporting on for example unused step definitions.
A roughly sketched example would look like this:
class StoryWritingMaintainableTestsTest {
@Test
void scenario_refactor_test_after_many_years() {
given_a_test_T_written_many_years_before();
when_test_T_breaks();
then_I_want_to_easily_understand_the_purpose_of_test_T();
}
...
}
The actual challenge is writing the story so that it describes a valuable story. A step which most of the time has no value for a story is when_I_click_button_B(). What if clicking a button is later replaced by speech recognition?
Conclusion
Actually I again would like to quote the Conclusion by Jakub Holy:
Given that most of bigger business software systems live for quite a number of years, it’s essential to write tests in such a way that they enhance and not limit the evolvability of the system. It is not easy but we must make efforts towards that.
To succeed we must structure our code and tests in a particular way and approach our test methods, test classes, and test suites as telling stories about what the code under test does.
Links
- Mike Cohn: The Forgotten Layer of the Test Automation Pyramid; 2009-12-17
- Martin Fowler: Test Pyramid; 2012-05-01
- agilefaqs: Inverting the Testing Pyramid; 2011-02-01
- Jakub Holy: Principles for Creating Maintainable and Evolvable Tests; 2011-11-30
- Wikipedia: Mock object
- Cucumber
- JBehave
