Here are a few interesting visualizations that I found while doing research for my talk about testing Insights, also included are the ones that I did not end up using:
- Open source contributions by location
- GitHut - is an attempt to visualize and explore the complexity of the universe of programming languages used across the repositories hosted on GitHub.
- Who speaks what on GitHub?
Visualization 1 is a chord diagram, which indicates the relationship between all possible combinations of programming languages. This data was computed by creating all possible pairs that could be created using the list of 20 languages I have analyzed. By analyzing the combinations, and the number of users that speak both of the languages in question, we get a good idea of what languages are spoken most, but also which languages are 'spoken' quite a lot, but not in combination. It gives a different perspective of the user-language landscape on GitHub.
Visualization 2 makes direct use of the structure of the MySQL database I described in the section above. It allows you to search for a particular username and find out which languages this users speaks. While not very revolutionary, it is a very natural and logical way to query the data I obtained.
Visualization 3 is the exact inverse of the second visualization. It offers you the capability of finding users that speak a given combination of languages. This may be useful if you're looking for a specific skillset for a project, and are looking for someone to help you out.
- The state of the Octoverse 2016
- Community Over the past year, GitHub partnered with, held, and sponsored events all over the world. At Patchworks we watched new developers learn how to use Git. Our ConnectHome partnership provided low-cost internet access for families living in HUD-assisted housing. Sponsoring events like Rails Girls and hosting our own conferences allowed us to meet more GitHub users than ever before.
- Newcomers This year GitHub grew by more than 5.2 million users and 303K organizations. We have more new students, developers, and businesses using GitHub than ever before.
- Organizations With almost 80M total Pull Requests on GitHub, we know that 85% of all requests for change come from within organizations.
- Tabs or spaces. We are going to parse every file among all programming languages known by GitHub to decide which one is on top.
- Programming language associations - Mapping organizations with projects on GitHub to their respective programming languages
- Analyzing emotions in texts based on the occurrence of expressions
- Amount of profanity in git commit messages per programming language
Some of us here are working on the BDD guidelines that should be followed:
Would be interested to hear if anyone has thoughts to share:
- Explain in the feature file what the feature is about, just after the “Feature:
” before proceeding to the scenarios (preferably in “In order/As a/I want” format).
- Write high-level scenario steps by raising the level of abstraction and focus on the “what” rather than the “how”
- don’t mention UI elements
- don’t mention ‘click’ or other actions linked to specific UI elements
- the scenario should remain valid if the UI is replaced with a new UI tomorrow
- avoid very detailed steps where possible (helps to focus and avoid clutter)
- Write scenarios using business language rather than using technical language so that it can be understood by everyone.
- Write scenarios from the perspective of the person who will use or needs the feature (not always a member or user). Use 'I' and explain who the 'I' is in 'Given' step.
- Each and every scenario needs to be independent, i.e. scenarios should not depend on other scenarios or data created by other scenarios.
- Don't mention features or actions which are not related to the actual feature under test.
- Example: Scenario is to check the balance is displayed currently in a user account. Before checking the balance, user needs to login to check the balance but Login is not part of the check balance scenario.
- Use Scenario Outline when you have several scenarios that follow exactly the same pattern of steps, just with different input values or expected outcomes.
- Scenario Outline examples should be easy to understand. Column names should be meaningful (e.g. | Contact Method | Enquiry Type | instead of | value1 | value2 | ), so that the steps are understandable.
- Scenarios need to be environment independent.
- Write scenarios for testing happy paths and important error cases.
- Avoid typos and always use grammatically correct English.
- Wherever possible steps should be reused. This can also be achieved by
- parameterizing (if applicable)
- keeping it short and simple
- Whenever a feature or behaviour changes the existing scenarios needs to be updated (from a latest branch in TFS)
- Actions, which are not directly related to the scenario should be handled outside the actual scenario:
- Actions like login should be handled part of Background or hooks.
- Setup and teardown should be part of hooks and should not be part of the scenario.
Same test as in Bad Example 1, but with focus on a single business rule and without UI stuff