Unittesting_AlexMeade
•Download as PPTX, PDF•
0 likes•57 views
Unit tests are small sections of code written during development to test individual parts of an application. They help find bugs earlier, improve code quality, act as documentation, and prevent defects from being reintroduced. Research shows unit tests can find 85% of defects during development and help implement features correctly the first time.
Report
Share
Report
Share
Recommended
Shifting Testing Left - The Pain Points and Solutions
Learn what shift left is, why it usually doesn't work and how to solve those problems. We will focus on test automation and the struggles of having it incorporated into the continuous integration (CI) or continuous deployment (cd) strategy.
Что нам стоіт таск манагер построіт. Ігор Лущик. LvivPy #6
Підсумує по огляду, тобто, що це, які вони є, юзкейси і чому не треба придумувати власний, а чому треба.
Move test planning before implementation
This document discusses improving the software development workflow by moving test planning earlier. It proposes defining acceptance criteria during feature planning to help test cases be "born" earlier. This would help avoid misunderstandings later on. It also advocates for more collaboration through daily stand-ups to catch issues early and learn from failures. The goal is to reduce bottlenecks and workload by improving planning, collaboration, and shifting left testing activities.
Exploratory testing
This is testing trends post, you got all testing related post , latest interview related post. All testing related material. Click the below link to find the my site, where you got all manual and automation testing related post.
Agile Quality and Risk Management
Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.
Wie man KI ins Testing bringt
Wenn KI die Zukunft des Testens ist, dann zeige ich Ihnen wie. Es gibt unzählige Automatisierungstools, aber dank hoher Erstellungs- und Wartungsaufwände ist GUI-basiertes Testen immer noch eine mehrheitlich manuelle Aufgabe (entsprechend der Testpyramide). Dabei macht Testen mittlerweile 30% des Gesamtaufwandes eines Softwareprojektes aus! Da ein Fehler im Auge des Betrachters liegt, ist es für eine KI schwer einen Fehler als solchen zu erkennen. Deshalb kann KI heute noch keine Tests automatisieren. Aber was, wenn es eine Möglichkeit gäbe dieses Problem zu umgehen? Ich zeige Ihnen, wie man heute eine KI trainieren und nutzen kann, um nicht nur technische Fehler zu finden, sonder automatisch Tests zu automatisieren! Besuchen Sie die Zukunft des Testens, und sehen Sie wie KI uns helfen kann Software besser zu machen.
Importance of test automation, excuses and TDD introduction
This document discusses test-driven development (TDD) and its benefits. It notes that research has found that TDD teams produce code with 60-90% fewer defects and take 15-35% longer to complete projects. Examples are given showing TDD teams needing fewer iterations to pass tests. The conclusion is that TDD results in less bugs, better code/design, test coverage of 100%, confidence, documentation, and decreased debug time, though tests can only find bugs, not guarantee their absence. Prevention of bugs is emphasized as better than later fixes.
Testing The Legacy: Making Existing Applications Testable Without Epic Efforts
If you have an established product which came about before the widespread use of the unit and system testing, then you know the problem.
The old code cannot be made testable without a significant effort of throwing it away and writing it anew.
What does it mean for the QA? It means endless repetitions of manual test runs. Sounds like fun? Yeah.. Nah!
In this presentation you will find two ways to make legacy applications testable through automation: an easy one, and a good one. The main benefit they provide is a basis for the further refactoring of the application, without damaging it.
Think of it as a Catch-22: you can't make your old app code testable without severely changing it, and you can't be sure that your changes work because you have no tests to verify them.
If you are a QA and you work with older apps and systems doing a lot of manual testing, then this is the topic for you.
This talk was given at ITx 2016 in Wellington, New Zealand, for Testing Professionals Network.
Recommended
Shifting Testing Left - The Pain Points and Solutions
Learn what shift left is, why it usually doesn't work and how to solve those problems. We will focus on test automation and the struggles of having it incorporated into the continuous integration (CI) or continuous deployment (cd) strategy.
Что нам стоіт таск манагер построіт. Ігор Лущик. LvivPy #6
Підсумує по огляду, тобто, що це, які вони є, юзкейси і чому не треба придумувати власний, а чому треба.
Move test planning before implementation
This document discusses improving the software development workflow by moving test planning earlier. It proposes defining acceptance criteria during feature planning to help test cases be "born" earlier. This would help avoid misunderstandings later on. It also advocates for more collaboration through daily stand-ups to catch issues early and learn from failures. The goal is to reduce bottlenecks and workload by improving planning, collaboration, and shifting left testing activities.
Exploratory testing
This is testing trends post, you got all testing related post , latest interview related post. All testing related material. Click the below link to find the my site, where you got all manual and automation testing related post.
Agile Quality and Risk Management
Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.
Wie man KI ins Testing bringt
Wenn KI die Zukunft des Testens ist, dann zeige ich Ihnen wie. Es gibt unzählige Automatisierungstools, aber dank hoher Erstellungs- und Wartungsaufwände ist GUI-basiertes Testen immer noch eine mehrheitlich manuelle Aufgabe (entsprechend der Testpyramide). Dabei macht Testen mittlerweile 30% des Gesamtaufwandes eines Softwareprojektes aus! Da ein Fehler im Auge des Betrachters liegt, ist es für eine KI schwer einen Fehler als solchen zu erkennen. Deshalb kann KI heute noch keine Tests automatisieren. Aber was, wenn es eine Möglichkeit gäbe dieses Problem zu umgehen? Ich zeige Ihnen, wie man heute eine KI trainieren und nutzen kann, um nicht nur technische Fehler zu finden, sonder automatisch Tests zu automatisieren! Besuchen Sie die Zukunft des Testens, und sehen Sie wie KI uns helfen kann Software besser zu machen.
Importance of test automation, excuses and TDD introduction
This document discusses test-driven development (TDD) and its benefits. It notes that research has found that TDD teams produce code with 60-90% fewer defects and take 15-35% longer to complete projects. Examples are given showing TDD teams needing fewer iterations to pass tests. The conclusion is that TDD results in less bugs, better code/design, test coverage of 100%, confidence, documentation, and decreased debug time, though tests can only find bugs, not guarantee their absence. Prevention of bugs is emphasized as better than later fixes.
Testing The Legacy: Making Existing Applications Testable Without Epic Efforts
If you have an established product which came about before the widespread use of the unit and system testing, then you know the problem.
The old code cannot be made testable without a significant effort of throwing it away and writing it anew.
What does it mean for the QA? It means endless repetitions of manual test runs. Sounds like fun? Yeah.. Nah!
In this presentation you will find two ways to make legacy applications testable through automation: an easy one, and a good one. The main benefit they provide is a basis for the further refactoring of the application, without damaging it.
Think of it as a Catch-22: you can't make your old app code testable without severely changing it, and you can't be sure that your changes work because you have no tests to verify them.
If you are a QA and you work with older apps and systems doing a lot of manual testing, then this is the topic for you.
This talk was given at ITx 2016 in Wellington, New Zealand, for Testing Professionals Network.
Amy Phillips - Take Control Of The Process - EuroSTAR 2013
EuroSTAR Software Testing Conference 2013 presentation on Take Control Of The Process by Amy Phillips.
See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Faster Secure Software Development with Continuous Deployment - PH Days 2013
This document discusses moving to a continuous deployment model to improve software security. It argues that the traditional release-based model is harmful, especially for security, as it results in long delays between when code is written and deployed. Continuous deployment aims to deploy small changes frequently, with developers pushing their own code to production. This gets developers more invested in the quality and security of the code they write. It also allows faster fixing of bugs and security issues when they are found. The document outlines steps to gradually implement continuous deployment and address common concerns about its impact on quality, compliance, and customers.
Making testability our mission
This is a call to action. On our cross functional teams and during our devops transformations we talk about how testing is for the whole team. Quality is everyone's responsibility. How much are we really doing to make this happen? Often we are working on systems that are hard to test for many reasons, but if we simply do more testing, write more automation we are neglecting what should be our main mission, advocating for increasing levels of testability, to truly get everyone involved in testing. We all have stories about how something is difficult to test, often never being tested or certainly left with the tester to figure it out. It doesn't have to be this way.
During my talk, I want to introduce a set of principles for testability engineering. A new way to approach our work as testers. These principles will tackle how we make our systems more observable, controllable, how we share knowledge across teams and improve the testability of our dependencies. I believe it is time to create a new focus on testability, as it affects everything we do, what our teams do and beyond into how value is delivered for customers.
I want you to take away from the talk:
* Why a focus on testability can multiply your effectiveness as a tester
* What the principles of testability engineering are and how to advocate for them
* How you can make iterative changes to what you do in order to embrace testability
New technology and complexity is rendering many software development techniques and paradigms obsolete at an increasing rate. We already exist in a space where an infinite number of tests of an array of different types can be performed. A new mission is needed, one that leverages the varied talents of all kinds of testers and culminates in a new focus on the exponential benefits that testability brings.
Continous testing for grails
Continuous testing tools like Auto-test and InfiniTest can help developers write better code faster by running tests automatically after each code change. A study found developers using continuous testing were three times more likely to complete programming tasks by the deadline and most participants believed it helped them work more efficiently. InfiniTest is recommended for use within IDEs like Eclipse due to its ability to provide test results within the same environment, while Auto-test may be better for non-IDE users.
Yelp Tech Talks: Mobile Testing 1, 2, 3
This document discusses testing approaches for mobile applications at Yelp. It describes how Yelp uses documentation, mocks, and JSON to test new mobile APIs on iOS and Android. It outlines the different types of tests Yelp employs, including unit tests, integration tests, and UI tests. For iOS, it details how KIF is used for integration testing. For Android, it explains how Espresso is used for UI tests along with techniques for addressing flakiness and speeding up test runs.
Static analysis tools as the best friend of QA
We have spent many years testing our applications and systems manually and with test automation tools. During this time many bug root causes have been classified and could be detected automatically with special static analysis tools. Most of them could be applied at the early stages of development even before code is integrated into the main development branch. In this talk, I will go through available solutions and demonstrate what kinds of issues may be detected automatically reducing the time and effort of traditional testing.
On the Care and Feeding of Feedback Cycles
Presented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy.
TDD for Testers
This document provides an overview of test driven development (TDD) principles and benefits. It discusses how TDD can be applied to both new and legacy code projects. The key benefits of TDD include better test coverage, less debugging, and improved design. Applying TDD requires discipline to write tests before code in small incremental steps. The document concludes that TDD is a valuable technique for all types of projects that requires persistence.
ATAGTR2017 Detect Layout Bugs by Simulating Human Eye
The presentation on Detect Layout Bugs by Simulating Human Eye was done during #ATAGTR2017, one of the largest global testing conference. All copyright belongs to the author.
Author and presenter : Surendran Ethiraj
Shifting is more than shifting left
Slides from Jesper Ottosen's 2017 Fall OnlineTestConf session – Shifting is more than shift left.
Change is happening to the testing activities. Shift-left automates and codifies the testing activities. Shift-right does it for production.
This session was about a couple of other trends, changes, and shifts that are happening to testers and test managers.
– Shift-Coach, where It’s more about coaching teams.
– Shift-SME, where it’s more about business savvy.
– Shift-Deliver, where it’s more about the road to production
www.onlinetestconf.com
SeleniumCamp 2015 Andrii Soldatenko
This document discusses high performance functional testing based on Selenium. It begins with an introduction of the speaker and outlines a testing pyramid with unit, integration and functional/UI tests. It then demonstrates how to automate functional tests for web applications using Selenium and discusses techniques for decreasing test execution time, including using Selenium Grid, PhantomJS, HTTP requests instead of Selenium, and parallel test execution. The document emphasizes that faster tests allow for faster development and provides approaches and tools to reduce test bottlenecks and optimize test execution time.
Making operations visible - devopsdays tokyo 2013
This document provides an overview of a presentation given by Nick Galbreath at DevOpsDays Tokyo 2013 about making operations visible. The presentation encourages organizations to expose more operational metrics and business data through systems like Graphite and StatsD to improve communication and collaboration between teams. It provides examples of how to collect and visualize different types of data from applications, systems, and business processes. The goal is to overcome excuses for lack of visibility and have organizations complete the "One Machine, One Day, One Person Challenge" to start exposing all of their operational metrics.
Openstack dev on
The document discusses OpenStack and its readiness for public service. It questions whether OpenStack is ready to handle issues like scalability, reliability, and security needed for public clouds. OpenStack responds that it provides basic tools and APIs, but that each implementation needs to address weaknesses and ensure their own applications and infrastructure are cloud-ready. It concludes that OpenStack provides open source tools, not complete solutions, and users need to improve upon and test the tools for their own needs.
Get testing bottlenecks out of your pipelines
When teams move towards continuous delivery and deployment, how do they manage the manual stages in their deployment pipeline? This talk gives some techniques to visualize pipelines, identify bottlenecks, find ways to remove them.
TDD on android. Why and How? (Coding Serbia 2019)
The document discusses test-driven development (TDD) on Android. It covers:
- The history and principles of TDD, including writing failing tests first and then only producing code to pass those tests.
- How TDD works in practice using the "red-green-refactor" process of writing a failing test, passing code, then refactoring.
- Benefits of TDD like fewer bugs, easier refactoring, and faster long-term development.
- Considerations for testing Android code, such as using mockable classes and avoiding direct testing of activities/fragments.
Peer Code Review: In a Nutshell
Development is inherently collaborative. So why aren't you doing code review? This session discusses the importance of collaboration around your source code, the impact code review can have on development teams, and offers guidance on how to get started.
Atlassian Speaker: Matt Quail
Customer Speaker: Patrick Coleman of Dash
Key Takeaways:
* Peer code review explained
* Benefits and approaches to effective code review
Why is mobile testing important?
Mobile testing is important to ensure apps work properly and do not experience crashes, freezing, or errors, which could cause 62% of users to uninstall. A QA department uses various tools like Slack, Trello, Zeplin, Postman, and Charles to heavily test apps and make sure they meet client needs and expectations. An innovation and QA lead at a company presented on the importance of mobile testing and demonstrated three tools - HockeyApp, AppFigures, and Postman - that can improve the quality of live apps.
Meet my CI
This document summarizes a company's plan to continuously increase code coverage across different technologies using a continuous integration (CI) system. It discusses moving from a single-server Jenkins setup to using multiple Jenkins masters and orchestrating jobs with Zuul to distribute work. It also covers monitoring logs with ELK and providing metrics to developers. The new approach resulted in 30,000 weekly job runs across 120 servers and 60,000 containers, with an average job time of 132 seconds, and was implemented in 3 months.
Daniel Cerecedo | From legacy to cloud... and beyond | Codemotion Madrid 2018
A case study of how a medium sized company moved a legacy java code base to the cloud. Considerations around microservices architecture, containerization, tooling, quality management, git flows and more. Understand the challenges faced, decisions made along the way and the impact of each one.
Find out more presentations at https://madrid2018.codemotionworld.com/speakers/
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
1) Initial bug fix discussions with more comments and more developers participating are more likely to experience later bug reworking through re-opening or re-patching of the bug.
2) Manual analysis found that defective initial fixes and failure to reach consensus in discussions contributed to later reworking.
3) For re-opened bugs, initial discussions focused on addressing a particular problem through a burst of comments, while re-patched bugs lacked thorough code review and testing during the initial fix period.
Unit Testing
The document discusses unit testing and provides guidance on how to effectively implement unit testing. It defines unit testing as testing individual units or components of software code to verify they are functioning as intended. The document outlines best practices for unit testing such as writing test cases that cover valid, invalid, and boundary conditions. It also recommends testing frameworks like JUnit that can automate running test cases. Overall, the document advocates for developing a rigorous unit testing strategy and practicing habits like writing tests first and continuously running tests to improve code quality.
Why Unit Testingl
The document discusses various aspects of unit testing including definitions, benefits, naming standards, and best practices. It provides definitions for terms like error, defect, failure. It outlines the benefits of unit testing like finding bugs early, enabling code refactoring. It discusses what should be tested like boundaries, error conditions. It also provides examples of good test names and guidelines for structuring and naming unit tests.
More Related Content
What's hot
Amy Phillips - Take Control Of The Process - EuroSTAR 2013
EuroSTAR Software Testing Conference 2013 presentation on Take Control Of The Process by Amy Phillips.
See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Faster Secure Software Development with Continuous Deployment - PH Days 2013
This document discusses moving to a continuous deployment model to improve software security. It argues that the traditional release-based model is harmful, especially for security, as it results in long delays between when code is written and deployed. Continuous deployment aims to deploy small changes frequently, with developers pushing their own code to production. This gets developers more invested in the quality and security of the code they write. It also allows faster fixing of bugs and security issues when they are found. The document outlines steps to gradually implement continuous deployment and address common concerns about its impact on quality, compliance, and customers.
Making testability our mission
This is a call to action. On our cross functional teams and during our devops transformations we talk about how testing is for the whole team. Quality is everyone's responsibility. How much are we really doing to make this happen? Often we are working on systems that are hard to test for many reasons, but if we simply do more testing, write more automation we are neglecting what should be our main mission, advocating for increasing levels of testability, to truly get everyone involved in testing. We all have stories about how something is difficult to test, often never being tested or certainly left with the tester to figure it out. It doesn't have to be this way.
During my talk, I want to introduce a set of principles for testability engineering. A new way to approach our work as testers. These principles will tackle how we make our systems more observable, controllable, how we share knowledge across teams and improve the testability of our dependencies. I believe it is time to create a new focus on testability, as it affects everything we do, what our teams do and beyond into how value is delivered for customers.
I want you to take away from the talk:
* Why a focus on testability can multiply your effectiveness as a tester
* What the principles of testability engineering are and how to advocate for them
* How you can make iterative changes to what you do in order to embrace testability
New technology and complexity is rendering many software development techniques and paradigms obsolete at an increasing rate. We already exist in a space where an infinite number of tests of an array of different types can be performed. A new mission is needed, one that leverages the varied talents of all kinds of testers and culminates in a new focus on the exponential benefits that testability brings.
Continous testing for grails
Continuous testing tools like Auto-test and InfiniTest can help developers write better code faster by running tests automatically after each code change. A study found developers using continuous testing were three times more likely to complete programming tasks by the deadline and most participants believed it helped them work more efficiently. InfiniTest is recommended for use within IDEs like Eclipse due to its ability to provide test results within the same environment, while Auto-test may be better for non-IDE users.
Yelp Tech Talks: Mobile Testing 1, 2, 3
This document discusses testing approaches for mobile applications at Yelp. It describes how Yelp uses documentation, mocks, and JSON to test new mobile APIs on iOS and Android. It outlines the different types of tests Yelp employs, including unit tests, integration tests, and UI tests. For iOS, it details how KIF is used for integration testing. For Android, it explains how Espresso is used for UI tests along with techniques for addressing flakiness and speeding up test runs.
Static analysis tools as the best friend of QA
We have spent many years testing our applications and systems manually and with test automation tools. During this time many bug root causes have been classified and could be detected automatically with special static analysis tools. Most of them could be applied at the early stages of development even before code is integrated into the main development branch. In this talk, I will go through available solutions and demonstrate what kinds of issues may be detected automatically reducing the time and effort of traditional testing.
On the Care and Feeding of Feedback Cycles
Presented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy.
TDD for Testers
This document provides an overview of test driven development (TDD) principles and benefits. It discusses how TDD can be applied to both new and legacy code projects. The key benefits of TDD include better test coverage, less debugging, and improved design. Applying TDD requires discipline to write tests before code in small incremental steps. The document concludes that TDD is a valuable technique for all types of projects that requires persistence.
ATAGTR2017 Detect Layout Bugs by Simulating Human Eye
The presentation on Detect Layout Bugs by Simulating Human Eye was done during #ATAGTR2017, one of the largest global testing conference. All copyright belongs to the author.
Author and presenter : Surendran Ethiraj
Shifting is more than shifting left
Slides from Jesper Ottosen's 2017 Fall OnlineTestConf session – Shifting is more than shift left.
Change is happening to the testing activities. Shift-left automates and codifies the testing activities. Shift-right does it for production.
This session was about a couple of other trends, changes, and shifts that are happening to testers and test managers.
– Shift-Coach, where It’s more about coaching teams.
– Shift-SME, where it’s more about business savvy.
– Shift-Deliver, where it’s more about the road to production
www.onlinetestconf.com
SeleniumCamp 2015 Andrii Soldatenko
This document discusses high performance functional testing based on Selenium. It begins with an introduction of the speaker and outlines a testing pyramid with unit, integration and functional/UI tests. It then demonstrates how to automate functional tests for web applications using Selenium and discusses techniques for decreasing test execution time, including using Selenium Grid, PhantomJS, HTTP requests instead of Selenium, and parallel test execution. The document emphasizes that faster tests allow for faster development and provides approaches and tools to reduce test bottlenecks and optimize test execution time.
Making operations visible - devopsdays tokyo 2013
This document provides an overview of a presentation given by Nick Galbreath at DevOpsDays Tokyo 2013 about making operations visible. The presentation encourages organizations to expose more operational metrics and business data through systems like Graphite and StatsD to improve communication and collaboration between teams. It provides examples of how to collect and visualize different types of data from applications, systems, and business processes. The goal is to overcome excuses for lack of visibility and have organizations complete the "One Machine, One Day, One Person Challenge" to start exposing all of their operational metrics.
Openstack dev on
The document discusses OpenStack and its readiness for public service. It questions whether OpenStack is ready to handle issues like scalability, reliability, and security needed for public clouds. OpenStack responds that it provides basic tools and APIs, but that each implementation needs to address weaknesses and ensure their own applications and infrastructure are cloud-ready. It concludes that OpenStack provides open source tools, not complete solutions, and users need to improve upon and test the tools for their own needs.
Get testing bottlenecks out of your pipelines
When teams move towards continuous delivery and deployment, how do they manage the manual stages in their deployment pipeline? This talk gives some techniques to visualize pipelines, identify bottlenecks, find ways to remove them.
TDD on android. Why and How? (Coding Serbia 2019)
The document discusses test-driven development (TDD) on Android. It covers:
- The history and principles of TDD, including writing failing tests first and then only producing code to pass those tests.
- How TDD works in practice using the "red-green-refactor" process of writing a failing test, passing code, then refactoring.
- Benefits of TDD like fewer bugs, easier refactoring, and faster long-term development.
- Considerations for testing Android code, such as using mockable classes and avoiding direct testing of activities/fragments.
Peer Code Review: In a Nutshell
Development is inherently collaborative. So why aren't you doing code review? This session discusses the importance of collaboration around your source code, the impact code review can have on development teams, and offers guidance on how to get started.
Atlassian Speaker: Matt Quail
Customer Speaker: Patrick Coleman of Dash
Key Takeaways:
* Peer code review explained
* Benefits and approaches to effective code review
Why is mobile testing important?
Mobile testing is important to ensure apps work properly and do not experience crashes, freezing, or errors, which could cause 62% of users to uninstall. A QA department uses various tools like Slack, Trello, Zeplin, Postman, and Charles to heavily test apps and make sure they meet client needs and expectations. An innovation and QA lead at a company presented on the importance of mobile testing and demonstrated three tools - HockeyApp, AppFigures, and Postman - that can improve the quality of live apps.
Meet my CI
This document summarizes a company's plan to continuously increase code coverage across different technologies using a continuous integration (CI) system. It discusses moving from a single-server Jenkins setup to using multiple Jenkins masters and orchestrating jobs with Zuul to distribute work. It also covers monitoring logs with ELK and providing metrics to developers. The new approach resulted in 30,000 weekly job runs across 120 servers and 60,000 containers, with an average job time of 132 seconds, and was implemented in 3 months.
Daniel Cerecedo | From legacy to cloud... and beyond | Codemotion Madrid 2018
A case study of how a medium sized company moved a legacy java code base to the cloud. Considerations around microservices architecture, containerization, tooling, quality management, git flows and more. Understand the challenges faced, decisions made along the way and the impact of each one.
Find out more presentations at https://madrid2018.codemotionworld.com/speakers/
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
1) Initial bug fix discussions with more comments and more developers participating are more likely to experience later bug reworking through re-opening or re-patching of the bug.
2) Manual analysis found that defective initial fixes and failure to reach consensus in discussions contributed to later reworking.
3) For re-opened bugs, initial discussions focused on addressing a particular problem through a burst of comments, while re-patched bugs lacked thorough code review and testing during the initial fix period.
What's hot (20)
Amy Phillips - Take Control Of The Process - EuroSTAR 2013
Amy Phillips - Take Control Of The Process - EuroSTAR 2013
Faster Secure Software Development with Continuous Deployment - PH Days 2013
Faster Secure Software Development with Continuous Deployment - PH Days 2013
ATAGTR2017 Detect Layout Bugs by Simulating Human Eye
ATAGTR2017 Detect Layout Bugs by Simulating Human Eye
Daniel Cerecedo | From legacy to cloud... and beyond | Codemotion Madrid 2018
Daniel Cerecedo | From legacy to cloud... and beyond | Codemotion Madrid 2018
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
Similar to Unittesting_AlexMeade
Unit Testing
The document discusses unit testing and provides guidance on how to effectively implement unit testing. It defines unit testing as testing individual units or components of software code to verify they are functioning as intended. The document outlines best practices for unit testing such as writing test cases that cover valid, invalid, and boundary conditions. It also recommends testing frameworks like JUnit that can automate running test cases. Overall, the document advocates for developing a rigorous unit testing strategy and practicing habits like writing tests first and continuously running tests to improve code quality.
Why Unit Testingl
The document discusses various aspects of unit testing including definitions, benefits, naming standards, and best practices. It provides definitions for terms like error, defect, failure. It outlines the benefits of unit testing like finding bugs early, enabling code refactoring. It discusses what should be tested like boundaries, error conditions. It also provides examples of good test names and guidelines for structuring and naming unit tests.
Why unit testingl
The document discusses unit testing and provides guidance on effective unit testing practices. It defines key terms like error, defect, and failure. It outlines the benefits of unit testing like finding defects earlier and maintaining stable code. It discusses naming conventions and frameworks for unit tests. It provides examples of different types of unit tests and guidelines for writing good unit tests that are independent, fast, and test all functionality. The document emphasizes testing boundary conditions and errors as well as documenting test cases.
Why Unit Testingl
The document discusses various aspects of unit testing including definitions, benefits, naming standards, and best practices. It provides definitions for terms like error, defect, failure. It outlines the benefits of unit testing like finding bugs early, enabling code refactoring. It discusses what should be tested like boundaries, error conditions. It also provides examples of good test names and guidelines for structuring and naming unit tests.
Test Driven Development
Test-driven development (TDD) is an agile software development process where test cases are developed before code. The TDD process involves writing a test, watching it fail, writing code to pass the test, and refactoring code as needed. TDD encourages dividing work into small pieces and promotes high-quality code by requiring tests to pass before adding new features. While TDD requires more initial time writing tests, it can reduce debugging time and defects in the long run.
Unit testing
This document discusses unit testing and provides an overview of its benefits and best practices. It defines unit testing as testing small pieces of code in isolation. It recommends writing unit tests for all code to check functionality and prevent bugs, and integrating testing into the development process by writing tests before code and ensuring tests pass before check-ins. The document also discusses test-driven development, refactoring code based on test results, and tools like NUnit that can automate the testing process.
Getting Started with Test-Driven Development at Longhorn PHP 2023
Test-driven development (TDD) is a software development process where test cases are written before code to validate requirements. The TDD process involves short cycles of adding a test, making it fail, making it pass, and refactoring code. Using TDD generates an automated test suite that gives developers confidence to refactor and change code quickly. Unit tests validate individual code units in isolation while feature tests validate code as a user would interact with it. Code coverage metrics help ensure tests cover enough of the codebase.
Unit Testing, TDD and the Walking Skeleton
The document discusses unit testing, test-driven development (TDD), and the walking skeleton approach. It provides an overview of these software development practices, including writing automated tests before code, using the tests to drive code development, and starting projects with an initial architecture or "walking skeleton" that is automatically testable, buildable, and deployable. The document aims to dispel common myths about testing and convince readers of the value of these practices.
TDD Best Practices
Ever tried doing Test First Test Driven Development? Ever failed? TDD is not easy to get right. Here's some practical advice on doing BDD and TDD correctly. This presentation attempts to explain to you why, what, and how you should test, tell you about the FIRST principles of tests, the connections of unit testing and the SOLID principles, writing testable code, test doubles, the AAA of unit testing, and some practical ideas about structuring tests.
Successful Teams are TDD Teams
The document discusses test-driven development (TDD) and acceptance test-driven development (ATDD). It notes that TDD involves writing tests before code to drive the design and ensure all tests pass, while ATDD focuses on testing business rules from the perspective of the team. The document advocates that successful teams use TDD and notes benefits like reduced defects and increased development time when adopting TDD practices.
Introduction to test programming
The document introduces test-driven development (TDD) and unit testing using NUnit. It discusses common excuses for not testing code and the benefits of unit tests. These include proving code works, reducing bugs, and making code easier to refactor. The document also outlines best practices for unit tests, such as running quickly, only failing for one reason, and minimizing dependencies. It introduces TDD workflows like red-green-refactor and describes some influential figures in agile software development and testing.
Google test training
The document discusses Google Test, an open source unit testing framework for C++ that can also be used for testing C code, providing an overview of its features and how to implement unit tests using common patterns like test fixtures, assertions, and death tests to validate expected failures. It also covers best practices for writing effective unit tests, including keeping tests independent, focused, and fast-running.
Understanding Unit Testing
Unit testing is a method to test individual units of source code to determine if they are fit for use. A unit is the smallest testable part of an application. Unit tests are created by programmers during development. Test-driven development uses tests to drive the design by writing a failing test first, then code to pass the test, and refactoring the code. Unit tests should be isolated, repeatable, fast, self-documenting, and use techniques like dependency injection and mocking dependencies. Benefits of unit testing include instant feedback, promoting modularity, acting as a safety net for changes, and providing documentation.
TDD (Test Driven Design)
4 Nisan 2015 tarihinde Kadir Has Üniversitesi'nde yapılan 9. Yazılım Teknolojileri Seminer etkinliğinde Eralp Erat'ın yaptığı TDD (Test Driven Design) sunumu
Test Driven Development
Test Driven Development (TDD) is a technique where tests are written before code to validate functionality. It promotes writing small testable units through the "red-green-refactor" process of writing a failing test, passing code, and refactoring. Popular unit testing frameworks for .NET like MSTest, NUnit, and xUnit allow automating tests that are fast, independent, repeatable, self-validating, and timely. Mocking frameworks like Moq and FakeItEasy generate stubs and fakes to isolate dependencies during testing. TDD helps reduce bugs and technical debt when refactoring legacy codebases lacking tests.
TDD Workshop UTN 2012
This was a workshop given on the UTN University, for the Software Engineering students. The idea is to give a brief explanation about TDD, and how to use it.
Test Driven Development
What is TTD?
Unit Test & Refactoring
Got Bugs?
Tenets of TTD.
Benifits of TDD.
Advantages & Disadvantages of TDD.
Unit testing_pps
Unit testing frameworks allow developers to test individual units or components of an application to ensure quality and avoid regressions. The document discusses unit testing and the OCUnit framework for iOS, including its history and how to write tests using asserts. Tests should be written in parallel with code using a test-driven development approach. OCUnit allows automatically running tests that validate the semantics of code.
Quality Assurance - The Other Side of the Fence
This document discusses different types of quality assurance testing for software, including unit testing, integration testing, and acceptance testing. It describes test-driven development (TDD) and behavior-driven development (BDD) approaches. TDD involves writing tests before code in small iterative cycles, while BDD is a collaborative way to define requirements to facilitate automated testing. The document provides guidance on writing effective behavior scenarios and assessing them.
Swiss Testing Day - Testautomation, 10 (sometimes painful) lessons learned
This document outlines 10 lessons learned about test automation from eBay. It provides facts about eBay, including that it has 27770 employees worldwide and processes 2 billion page views and 75 billion database calls daily. The lessons recommend flipping the testing triangle to focus more on automation, ensuring everyone knows what is automated, using test aspects to guide automation, and treating automation as software development. It emphasizes the importance of maintainability, using the same language as developers, investing in test infrastructure, and that manual testing remains important alongside automation.
Similar to Unittesting_AlexMeade (20)
Getting Started with Test-Driven Development at Longhorn PHP 2023
Getting Started with Test-Driven Development at Longhorn PHP 2023
Swiss Testing Day - Testautomation, 10 (sometimes painful) lessons learned
Swiss Testing Day - Testautomation, 10 (sometimes painful) lessons learned
Unittesting_AlexMeade
- 1. Why are they important? Alex Meade ITEC 490
- 2. What are Unit Tests? Written during development Test smallest sections of code possible Work together to test all of the code Detects bugs earlier
- 3. Project Quality Improves codebase design Acts as documentation Prevents introducing defects
- 4. Fewer Defects 85% of defects are introduced in development Stops reoccurring defects Implements features right the first time
- 5. References Hevery, Misko. The Clean Code Talks: Unit Testing. Google Tech Talks. 30 Oct. 2008. 26 Nov. 2011. <http://www.youtube.com/watch?v=wEhu57pih5w>. Video. IPL. Why Bother to Unit Test. Information Processing Ltd. 18 Mar. 2011. 26 Nov. 2011. < http://www.ipl.com/pdf/p0828.pdf> Martin, Robert. The Clean Coder. Boston: Prentice Hall, 2011. Print. Rajendran, R. Venkat. White paper on Unit Testing. Deccanet Designs Ltd. <http://www.mobilein.com/WhitePaperonUnitTesting.pdf> “Why Unit Testing?” agitar.com. Agitar, n.d. 26 Nov. 2011. < http://www.agitar.com/solutions/why_unit_testing.html>