📆
2021-05-02
In The Clean Coder, Chapter 7 (Acceptance Tests), Robert C. Martin writes (p. 109):
But the real reason these tests aren’t redundant is that their primary function is not testing. The fact that they are tests is incidental. […] The fact that they automatically verify the design, structure, and behaviour that they specify is wildly useful, but the specification is their true purpose. [Bold emphasis mine.]
OK, boomer, here’s your spec:
📆
2020-08-05
In my last article, I outlined the purpose of a stock program: a non-trivial coding exercise to be done in every new programming language somebody is learning. I also stated that «Four in a Row» is becoming my personal stock program, and that I’d like to implement it in Haskell.
The main challenge in Haskell is the functional programming paradigm. Immutability is the main difference between an implementation of «Four in a Row» in a functional programming language compared to rather structured programming languages such as C or Python.
📆
2020-08-03
In a recent interview, Brian W. Kernighan said that he always re-implements the same program when he’s learning a new programming language. In his case, it’s a programm to process a text file containing a variable number of lines. In this task, his programming language AWK (Kernighan is the «K» in «AWK») shines, for it was designed for that kind of a task.
Such a stock program allows to evaluate a programming language from a certain perspective.
📆
2020-07-22
Many universities teach programming in Java. Writing unit tests is one of the subjects being taught. Many professional Java programmers, but also university professors, suggest to build those test cases according to a pattern. Given, When, Then is a common pattern, and so is Arrange, Act, Assert. Both patterns prescribe the following structure for a test case:
Given/Arrange: An environment (in the broadest sense) is built up. When/Act: The function or method to be tested is invoked.
📆
2018-12-16
Programming is the process of writing code in order to solve a problem. Software Engineering is programming, combined with the factors time and other programmers. (I owe this insight to Russ Cox.)
Tests cannot prove the correctness of a program. A test case makes sure that a couple of hand-picked values from the input set are mapped correctly to a couple of hand-picked values from the solution set. As Dijkstra wrote, in order to get a program right, forget about the individual items of the set and work with the set definition—which is quite the contrary of writing test cases.
📆
2018-10-18
I’m doing a bachelor’s degree at a university of applied sciences with its own computer science department. I work part-time besides and already have a couple of years of practice in the field. In fact, I’ll soon reach the point of being longer in IT than I have spent time outside of it, for I’m already 31 years old and started my apprenticeship at the age of 16.
I’m mostly interested in programming.
🇬🇧
Cargo CultGetting it Wrong by Wanting it Right
📆
2018-10-05
Accepting interfaces instead of requiring specific implementations is a good practice. Take Java collections as an example. A method accepting an ArrayList argument will only be useful if the caller is already using an ArrayList. Otherwise he’d need to convert the implementation he’s using, say, LinkedList, to an ArrayList first. A method accepting the List or even the Collection interface is far more likely to accept what the caller already has.