Day 4 Q&A

Icebreaker questions

• Q:
  • A:
• Q:
  • A:
• Q:
  • A:
• Q:
  • A:

OO and Development

• Q: My programming is mostly limited to object-oriented programming. What is the main benefit of this approach, and what are the benefits of other methods? Maybe this is too broad a question, but perhaps you have any useful material to read up on. I can imagine this could be a nice addition to the course.

  • A: I will link to some more indepth material in the notes_paradigms.md but will try to be more verbose as well.
  • A: A good introduction to OO is the Object oriented Software Enginering book by Ivar Jacobson (one of the big brains behind RUP)
  • A: Principles of Object-Oriented Programming
    by Dung Nguyen, Stephen Wong Free ebook
  • A: not strictly in confict with other methods of development
  • A: Benefits with OO:
    • information hiding
      • by default other objects do not know about the content/attributes/methods to other objects
      • you can define access to be able to interact with specific attributes/methods (public) to another object
    • units programmable by different people
    • suitable for data operating on itself
    • User interface (UI) and other complex systems
      • Example: UI part different for different plattforms whereas rest of code the same
  • Drawbacks: if many objects, execution time may increase
  • Functional approach: functions operate on data!
  • small scripts may be over enginered when doing object modeling remeber development time can allso be considerd part of the wall time of an application.

• Q: What is difference between private, protected and package private?

  • A: Protected means that a class and its subclasses have access to the variable,
    • but not any other classes, they need to use a getter/setter to do anything with the variable.
  • A private means that only that class has direct access to the variable,
    • everything else needs a method/function to access or change that data.
  • package private: Module related. Things are accesible from within a module with several classes.
  • package privarte: is mostly a specifc thing to Java as it the default access specifier for a class, methond or variable where the deafult access is to be visable to all classes inside a package (which is a namespace module in Java) It is not a recomended practice to rely on default access parameters

Testing

• Q: If you have functions that implicitly rely upon another function, how do you perform a unit test then? Is it better practice to dummy the implicit function, or make it an integration test?

  • A: There are different schools but I prefer the classical view. Only mock if you really need to.

• Q:
  In your example, you test reverse for one word. I assume one would want to test the reverse for different words. Would one create a different test for each word or would one combine them into one test?

  • A: A common way to do this is by parametrizing the test function. This is a featured included in most testing suites. For pytest you can read about it here: https://docs.pytest.org/en/6.2.x/parametrize.html

• Q: How do you set up test? do you create a test function inside the main function or should it be outside the function that is testing like in the exercise? Should we put the test function inside one script or multiple test in different .py?

  • A: Tests should be on their own, not included in the deployed package or at least in another directory clearly seperated from production code.
  • Sometimes you want the user to make a test that the installation worked…

• Q: I never used an IDE, can you suggest one?

  • A: Which IDE (Integrated development environment) is best for you might depend on the language you are mainly writing in as well as personal preference. However, VSCode is very popular and works very well for most languages and platforms! For Python another common alternative is Pycharm. For Rust, C, C++ you have Clion and Visual Studio. For R you have R studio. This being said, most IDE features come from the language server protocol(LSP: https://microsoft.github.io/language-server-protocol/) and this can be configured for any IDE/editor like e.g. Vim and Emacs.

• Q:When are unit tests only enough?

  • A: You should never rely on just unit tests, but unit tests will reduce the need to test manually.

• Q: How unit tests related to coverage?

  • A: Coverage is a measures of the extent to which your code is being tested.

• Q: Are you suppose to write unit test along with the development or after? At the beginning there is a lot of prototyping and changes

  • A: The ideal is to write tests before writing the program. Probably you know the expected behavior of your program before writing. How to get there is subject to prototyping and implementation.

• Q: Should a unit test multiple conditions? The one in the exercise used only one world for instance, should one generally try many words?

  • A: I would say its a good idea to test cases that are qualitatively different. In the example of reverse string, this could be also testing strings with capital letters and spaces. /Matias

• Q: In case of the calculator, how many additions should you test to be sure that additions works?

  • A: A hard one to answer but with unit tests you can always add a new one if there is a bug. Then will have covered this case. We will look at ways to work with this later on.

• Q: In the calculator example, would e.g.. exception handling (entering a letter instead of number) be part of unit testing?

  • A: Yes, absolutely.

• Q: What is pros and cons for unit test compared with other types of test?

  • A: If you test each unit independently you can easily spot where in the code you have a bug. If each unit works your whole code should hopefully also work. However, there might be bugs that only come up once all units interact (This is where integration testing comes in). It can also be time consuming to write unit tests if you want a satisfactory coverage.

• Q: Will you push the refactored file to repo?

  • A: The "solution" for the refactoring exercise is pushed to a branch in the repo. The "person number" code is coming up within shortly.

• Q: In testesB the test of on a function is based on another funciont, mostly the find funciotn. So if the find fail also all other tests will fail. For instance I changed only the add function but the test failed because I didn't change the find. Shouldn't one test one function at the time?

  • A:This is a very good question, I will comment on it when we resume after lunch.

• Q: (Mocking) If my program reads and writes files, I should use mocking to simulate this or what do you recomment?

  • A: That depends, I think. As said before if you can do without mocks that has benefits. One technique that we did not touch in this session is test containers, with which you set up a testing environment in a docker container for each test. This allows for tests to become isolated even when touching filesystem. Some will argue whether this is a unit test or an integration test but either way such a test could probably test more and be more stable than one that is using mocks. Still, this test may be slow and there may be reason to use mocks to test the logic in the program.

Continuous integration session

• link to website: https://uppmax.github.io/programming_formalism-automated_testing/

• Q: Have you used GitHub actions before?

  • yes: ooo
  • no: ooooo

• Q:

General questions

• for python users, there is a library called nbdev, which is rendering notebook and testing everytime you push to github. In this case, the pushing to github represent a "test". What do you think is the best approach? Is it recommendable to use an external library to make tests?
  • A: Somtimes external libraries i.e. not included in core or stdlib are the best solution. Python has a builtin solution for testing https://docs.python.org/3/library/unittest.html however pytest (which is external) is more or less the standard. Letting GitHub run the tests as with nbdev relates to continuous integration which we will talk about from 14:30.

Questions above this line

Day 4 feedback

• F: Github actions went horribly wrong, but I think it was very informative.
• F: It is rather useful to share those 'sourcery' refactoring tool to have first overview, accepting it or not, it will require experience to judge.
• F: I really appreciated the testing session. Having programming exercises and code along makes the presented theory actually usable in my work.
• F:
• F: