Engineering Practices

You can suggest amendments via this Google Form.

Question Answer Rating

Why do we write To ensure the code behaves as expected and to prevent regression as the software grows. Easy
tests?

Describe some testing (Open-ended. Depends on the particular software stack used.) Easy
tools and frameworks
you've used. For Python (e.g.):

The built-in unittest module.

Extensions, such as nosetests or pytest (additional or specialised assertions).
Test runners (again nosetests or pytest).
Test verification and mocking (and stubbing), e.g. mockito (Python 3 has built-in support for mocks).
Monkey-patching (because Python is a dynamic language).

Describe a generic Medium

/typical continuous
integration (CI)
process (steps).
Note: This is really
just a cover for
checking which
engineering practices
a developer follows.
Check out project from version control
Checking for copyright notices (and other business or legal requirements)
Generating a unique version number for the build
Resolve and install dependencies (local and third-party)
Testing with code coverage
Check for code duplication
Static analysis (and possibly reverse engineering class diagrams, etc.)
Generating documentation
Packaging and producing the deployable artefact (installer, ZIP file, etc.)

Where is the CI stops where the deployable artefact is produced, which is where CD starts. Logically CD transcends CI. Medium
implementation
boundary between a
CI and CD
(continuous delivery)
process?

What are the Medium

characteristics of Fast: The faster tests execute, the more often it can be run, and the easier to debug.
good tests? Isolation: A test should focus on a single scenario, and be clean of external dependencies, not share some
common state (i.e. tests must not be dependent on order).
Repeatable: A test must be deterministic. Typical problems include over-specialisation (the test is too specific
and test mundane details), volatile subsystems (shared state, e.g. a database, that could change), or
uninitialised memory (arguably a bug).
Self-verifying: A test must be unambiguous (the result/outcome of a test must not be open to human
interpretation).
Timely: Write your tests first: It defines the specification for what you are about to build. Writing tests after the
fact often leads to bad design and untestable code.

Note: The above is also known as the FIRST acronym.

Could you mention Medium

and discuss a few
types of tests? What
is the pyramid of
testing?
Unit test: Testing different permutations or code paths through a unit of code (usually small, e.g. a module or
function).
Integration test: Testing across the boundary of two units (usually to test or verify the interfaces).
Functional test: Testing a larger (sometime end-to-end) behaviour (i.e. functionality, not a function).
Non-functional test: E.g. testing for scalability, performance, security or other operational requirements.
Acceptance tests: A type of high-level test to confirm behaviour against a specification (e.g. UAT).

The pyramid of testing essentially means that the most tests in a stack are unit tests, on top of which integration
and functional tests follow, and at the top acceptance tests. The reasoning is that acceptance tests are usually
hard to automate and become error prone: Errors that can be caught a lot easier by lower levels of testing. Hence,
the number of tests increase towards the top.

What's the difference A mock tests behaviour and has a verification step (it verifies expectations), whereas a stub returns a Hard
between mocks and predetermined value. E.g. with a mock it can be tested that a particular method is invoked multiple times with
stubs (both being test particular parameters, and a stubbed method can be used to temporarily replace a large database lookup ("canned
doubles)? answers") where the test isn't as such concerned by what's returned by the database, but rather wants to test other
behaviour.