1. Properties of a good unit test
1.1. Small scope
1.2. Able to be fully automated
1.3. Has full control over all the pieces running (uses mocks or stubs when needed)
1.4. Can be run in any order
1.5. Runs in memory
1.6. Low-level, focusing on a small part of the software system. Written by the programmers themselves using their regular tools, these should be significantly faster than other kinds of tests
1.7. Constantly returns the same results
1.8. Runs fast
1.9. Tests a single logical concept (unit) in the system
1.9.1. What is a Unit?
1.9.1.1. OOD tends to treat a class as the unit, proedural or fnctional approaches migh consider a single function as a unit.
1.9.1.2. Situational thing; team decides what makes sense to be a unit for the purposed of their understanding of the system and its testing.
1.10. Readable
1.11. Maintainable
1.12. Trustworthy
2. Testing Tools
2.1. Xunit
3. Related
3.1. TDD
3.2. ExtremeProgramming (XP)
3.3. SelfTestingCode
3.3.1. Programmers run unit tests after any change to the code
3.3.2. Only need to run tests operating on that part of the code you're working on
3.4. Integration Testing
3.4.1. Manual Integration Tests
3.4.1.1. Pro
3.4.1.1.1. Testers cheaper than developers
3.4.1.1.2. Testers can intelligently adjust test to changes in the application; not inherently brittle as automated tests.
3.4.1.1.3. Testers can spot bugs an automated test might miss.
3.4.1.1.4. Does not require extra testing software which can be costly.
3.4.1.1.5. Always possible
3.4.1.1.6. You can just start, cost for doing a single test much lower than setting up and implementing an automated test
3.4.1.2. Con
3.4.1.2.1. You have to pay someone to do it every time, in the long run that's expensive
3.4.1.2.2. Full regression testing after bug fixes is basically impossible
3.4.1.2.3. You have to be very conservative with changes late in the development cycle and big changes in general. No constant refactoring - better live with bad code than risk catastrophic side effects
3.4.1.2.4. You have to plan very carefully when you'll do the testing to get the maximum value for the money. TO some degree you'll have to adjust your development practises to reflect that.
3.4.2. Defined: Unit tests should have no dependencies on code outside the unit tested. You decide what the unit is by looking for the smallest testable part. Where there are dependencies they should be replaced by false objects, mocks, or stubs. Test execution thread starts and ends within the smallest testable unit. When false objects are replaced by real objects and tests execution thread crosses into other testable units. you have an integration test
3.5. Automated unit tests allow your developers to code tests that automatically validate code according to their understanding of the specifications.
3.6. Manual testing will reveal problems from the point-of-view of users.
3.7. Black box testing
4. Why Write Units Tests?
4.1. Some Wrong Reasons
4.1.1. Management tells you to do it
4.1.2. Do it becuase everyone else is doing it.
4.1.3. My code is broke, I'm way over deadline, and we're all desperate.
4.2. Some Right Reasons
4.2.1. When changes are made to the code you have a bunch of automated tests to make sure something doesn't break.
4.2.2. Code is tested more rigourously
4.2.3. Make code better if tests are written first, then write code to pass the tests
4.2.4. Makes testing easier. Don't have to run the application over and over to simply get to a point where a block of code is executed.
4.2.5. When something fails, writing a unit test for that failure guarantees that it's fixed for once and for all
5. Meaningful coverage
6. Getting testers involved
7. Definition
7.1. The practice of testing certain functions and areas, or units, of code. This allows us the ability to verify our functions work as expected.
7.2. Determine if the function returns proper values and gracefully handles failure when invalid input is provided.
7.3. Ultimately helps to identify failures in algorithms and / or logic to help improve the quality of the code that comprises a certain function.
8. Collaborator Isolation
8.1. Should the unit being tested be isolated from it's collaborators?
8.2. Instead of using real product or custom classes you use TestDoubles for the collaborators.
8.3. Most unit testers do not isolate unless communicating with collaborator is awkward
8.4. Lack of isolation is criticized for use of term unit testing, Write tests assuming everything other than that unit is working correctly.
8.5. Two schools of xunit testing developed; classic and mockist styles (mockist care about isolation)
8.6. solitary tests: use collaborator isolation
8.7. sociable tests: those that don't
9. Talks
9.1. 2015 08 31
9.1.1. Reason for discussion
9.1.1.1. Duplication of effort between testers and unit testing.
9.1.1.2. Questionable thoroughness of existing Unit Tests
9.1.1.2.1. Does each Unit Test test for all possible code paths and/or data combinations?
9.1.1.3. We want to catch bugs earlier; cheaper to fix, dev can catch these bugs earlier (less communication, communication can be slow or inaccurate), minimizes manual testing effort (expensive)
9.1.1.4. Idea is for testers are to get involved in helping to design better more thorough unit tests.
9.1.2. How is a unit defined? Does the dev team decide on what this is?
9.1.3. Why not 100%?
9.1.3.1. Code coverage is a meaningless statistic so why do we continue to use it?
9.1.4. When we don't have 100% unit test coverage how do testers know where the holes are?
9.1.5. For testers Integration Testing > Unit Testing
9.1.6. Generally unit testing within Rangle and specifically unit testing within each project.
9.1.7. Can Unit Tests replace Manual Testing?
9.1.7.1. Black Box Testing
9.1.8. How do we test Unit Tests? How do we know they work?
9.1.9. Collaborator Isolation?
9.1.9.1. Is there a test strategy for unit testing?
9.1.10. Should testers test areas covered by Unit Tests?
9.1.11. Jacky found a regression bug which was covered by a unit test and the unit test indicated it passed. Knowing this how do we trust unit testing?