Development and Testing
Objective
- Identify the main stages of development and testing.
- Learn how to develop and test software projects.
Hacker Laws (opens in a new tab): Laws, theories,
principles, and patterns that developers will find useful. #hackerlaws
The Mythical Man-Month (opens in a new tab) book and No Silver Bullet (opens in a new tab) paper by Fred Brooks.
Principles
- Perfect is the enemy of good (opens in a new tab)
- KISS (opens in a new tab)
- DRY (opens in a new tab)
- YAGNI (opens in a new tab)
- Less is more (opens in a new tab)
- Worse is better (opens in a new tab)
- If it ain’t broke, don’t fix it (opens in a new tab)
- Unix philosophy (opens in a new tab)
- Rule of least power (opens in a new tab)
- Principle of least privilege (opens in a new tab)
- Single source of truth (opens in a new tab)
- Wirth’s law (opens in a new tab)
- Occam’s razor (opens in a new tab) (Principle of parsimony)
- Progressive disclosure (opens in a new tab)
- Satisficing (opens in a new tab)
- Feature creep (opens in a new tab)
- SMART criteria (opens in a new tab)
- Wabi-sabi (opens in a new tab) (侘び寂び)
Development
“There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.” —Leon Bambrick
Exercise 1
Create an application using JavaFX that converts temperature from Celsius to Fahrenheit and vice versa.
Testing
“If debugging is the process of removing bugs, programming must be the process of putting them in.” —Edsger Dijkstra
The following types of testing may be relevant:
- Unit testing (opens in a new tab)
- Integration testing (opens in a new tab)
- System testing (opens in a new tab)
- Regression testing (opens in a new tab)
- White-box testing (opens in a new tab)
- Black-box testing (opens in a new tab)
- Test automation (opens in a new tab)
- Basis path testing (opens in a new tab)
- Decision-to-decision path (opens in a new tab) testing
- Acceptance testing (opens in a new tab)
- Performance testing (opens in a new tab)
- Non-functional testing (opens in a new tab)
Unit Testing
“More than the act of testing, the act of designing tests is one of the best bug preventers known.” —Boris Beizer
The product can also be specified using tests before implementing the code:
- Test-driven development (opens in a new tab) (TDD)
- Behavior-driven development (opens in a new tab) (BDD)
- Data-driven testing (opens in a new tab) (DDT)
A test double (opens in a new tab) is a generic term for any case where you replace a production object for testing purposes: dummy (opens in a new tab), stub (opens in a new tab), spy, fake, mock (opens in a new tab). A test harness (opens in a new tab) is a collection of stubs (opens in a new tab) and drivers (opens in a new tab) configured to assist with the testing of an application or component.
Exercise 2
Follow the Get started with JUnit (opens in a new tab) guide to create and test a basic calculator application.
Exercise 3
Create and run unit tests for the application from Exercise 1.
Static Analysis
Exercise 4
Follow the Improving your code (opens in a new tab) guide to learn how to incorporate SonarQube (opens in a new tab) into your development environment and lifecycle.
Profiling
Exercise 5
Follow the profiling (opens in a new tab) guide to learn how to analyze applications in IDEA.
Collaboration
“Talk is cheap. Show me the code.” —Linus Torvalds
Structure
.gitignoremvnwmvnw.cmdpom.xml
.gitignoremvnwmvnw.cmdpom.xml
Resources
- JavaFX examples: 1 (opens in a new tab), 2 (opens in a new tab)
- JavaFX: Sample applications for tutorials (opens in a new tab)
- Debugging Java code in IntelliJ IDEA (opens in a new tab)
- Understanding mocks, stubs, and fakes in software testing (opens in a new tab)
- Mock, stub, spy and other test doubles (opens in a new tab)
- Test double (opens in a new tab), Mocks aren’t stubs (opens in a new tab)
- The little mocker (opens in a new tab)
- Non-functional testing (opens in a new tab), Non functional testing – A detailed overview (opens in a new tab), What is non-functional testing? (opens in a new tab)
- Systems development life cycle (opens in a new tab), Test-driven development (opens in a new tab), Behavior-driven development (opens in a new tab), Data-driven testing (opens in a new tab)
- Rubber duck debugging (opens in a new tab), Desk checking (opens in a new tab), Duck test (opens in a new tab), Software testing (opens in a new tab), Hooking (opens in a new tab), Software quality (opens in a new tab), Software quality assurance (opens in a new tab), Capability maturity model (opens in a new tab), Non-functional testing (opens in a new tab), Static program analysis (opens in a new tab), Profiling (opens in a new tab), Code coverage (opens in a new tab)
- Team programming (opens in a new tab), Software peer review (opens in a new tab), Code review (opens in a new tab), Technical peer review (opens in a new tab) Pair programming (opens in a new tab), Joint attention (opens in a new tab) Socratic method (opens in a new tab), Body doubling (opens in a new tab), Software inspection (opens in a new tab) Software walkthrough (opens in a new tab), Think aloud protocol (opens in a new tab), Rogerian argument (opens in a new tab), Pointing and calling (opens in a new tab), Learning by teaching (opens in a new tab)
- Eureka effect: The Aha! (opens in a new tab)