5. Fail fast. Check input and fail on nonsensical input or invalid state as early as possible, preferably with an exception or error response that will make the exact problem clear to your caller. Permit "innovative" use cases of your code though (i.e., don't do type checking for input validation unless you really need to).
Search
12 results for “voidbot”
-
2. Tests don't need testing. Infrastructure, frameworks, and libraries for testing need tests. Don't test the browser or external libraries unless you really need to. Test the code you write, not other people’s code.
-
6a. Unit tests test to the unit of behavior, not the unit of implementation. Changing the implementation, without changing the behavior or having to change any of your tests is the goal, although not always possible.
So where possible, treat your test objects as black boxes, testing through the public API without calling private methods or tinkering with state.
-
28. Generally, particularly in tests, wait for a specific change rather than sleeping for an arbitrary amount of time. Voodoo sleeps are hard to understand and slow down your test suite.
-
21b. Make code correct first and fast second. Writing a test that exercises the code you’re profiling with timing around it makes knowing when you’re done easier, and can be left in the test suite to prevent performance regressions.
(With the usual note that adding timing code always changes the performance characteristics of the code, making performance work one of the more frustrating tasks.)
-
1b. YAGNI: "You Aint Gonna Need It". Don't write code that you think you might need in future, but don't need yet.
The same is true for commenting-out code; if a block of commented code is going into a release, it shouldn't exist. If it is code that may be restored, make a ticket and reference the commit hash for the code delete. YAGNI is a core element of agile programming. The best reference for this is Extreme Programming Explained, by Kent Beck.
-
25. Generators rock! They’re generally shorter and easier to understand than stateful objects for iteration or repeated execution. A good introduction to generators is "Generator Tricks for Systems Programmers", by David Beazley. https://www.dabeaz.com/generators/
-
15. The more you have to mock out to test your code, the worse your code is. The more code you have to instantiate and put in place to be able to test a specific piece of behavior, the worse your code is. The goal is small testable units, along with higher-level integration and functional tests to test that the units cooperate correctly.
-
30. And finally, a point for management: Constant feature grind is a terrible way to develop software. Not letting developers take pride in their work ensures you won’t get the best out of them. Not addressing technical debt slows down development and results in a worse, more buggy product.
-
1b. YAGNI: "You Aint Gonna Need It". Don't write code that you think you might need in future, but don't need yet.
The same is true for commenting-out code; if a block of commented code is going into a release, it shouldn't exist. If it is code that may be restored, make a ticket and reference the commit hash for the code delete. YAGNI is a core element of agile programming. The best reference for this is Extreme Programming Explained, by Kent Beck.
-
6a. Unit tests test to the unit of behavior, not the unit of implementation. Changing the implementation, without changing the behavior or having to change any of your tests is the goal, although not always possible.
So where possible, treat your test objects as black boxes, testing through the public API without calling private methods or tinkering with state.
-
2. Tests don't need testing. Infrastructure, frameworks, and libraries for testing need tests. Don't test the browser or external libraries unless you really need to. Test the code you write, not other people’s code.