4 ms·

As a software developer,how do you test your design?

• john_the_writer 3y ago
  TDD. 100%. Design on paper first, and then convert those paper thoughts into tests. As you're writing your tests out, you'll think of edge cases and it will take a second or two to write a test header for it. Before you have a line of code, paper and pencil are your best friends.
  • donnie12345 3y ago
    Thanks How do you reason about program? Do you workout examples by hand ? Or prove it formally by mathematics
    • lcnPylGDnU4H9OF 3y ago
      (Not the person you responded to.) I will actually execute the program in most cases. Most of the development I do is in the context of a web request (server) or browser DOM (client) so running some quick snippet of code might be as simple as initiating a request from my browser to see what the server does or interacting with it in some other way which triggers the client-side stuff. You're going to have "something you start with" (input) and "what you want it to be" (output). Understanding these things will go a long way to reason out what you need to actually do to accomplish your goal. Usually a program's "goal" is to "output the correct thing" and the programmer will have to know what "correct" is. Certainly no formal proofs and I usually work things out "in my head", as it were, because it helps me to understand the problem that I'm working on. See also "rubber ducking" (https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging). It might help to try to build a small program to better wrap your head around "what" programming is.
    • john_the_writer 3y ago
      I don't do formal proofs, or use maths for proof. Most time the math is overkill. Yes I can show that indexing field [x,y] improves speed, but bench marks work here better than math. I just think of the thing I want to build, and I break it into smaller and smaller bits. I don't write code on paper.. just the "what do I want to happen".. super high level.
• logicalmonster 3y ago
  What does the comment "test your design" mean? Are you mostly referring to eliminating potential coding bugs, or are you referring more to "did I build the right interface/UI/UX to solve a particular problem?"
  • donnie12345 3y ago
    Eliminate potential bugs in the program earlier in the process. I.e to avoid programming by coincidence
    • logicalmonster 3y ago
      Until humans come up with a better way of building software, something like TDD seems to be the best way to build correct software. Keep in mind though that tests are also software built by humans that can be wrong too, sometimes giving you false confidence about correctness. The best test of a system is always real-world usage.
• swami108 3y ago
  TDD is the second best method. The first is developing good habits—list out all edge cases and just manually test it out. If you work in a team, the PM, developers, and QA can brainstorm these edge cases together. It’s these simple things that make a huge difference and you’d be surprised how many teams don’t do this.
• Jtsummers 3y ago
  Prototypes. When you have a design element in mind, you prototype it. This may mean writing multiple programs before producing the final program(s). Using the same language for your prototypes as for your final (target) system mitigates the concern there because you can take components of your prototypes and turn them into modules/libraries used by the final system. Testing. Always test the system. Automate every test you can so you can trigger them and get a report once completed rather than wasting your time clicking buttons or typing in commands.
• beginnings 3y ago
  I don't design or test, that sounds like some stuff you'd be forced to do in school. It's stepping stones, I don't know where the next one will be but I know ill work it out when I get there. I build in a pretty modular, loosely coupled way, the correct structures reveal themselves as you go, you'd need to be a Tesla level genius to work it all out from the start and not make mistakes. I handle the things i'm aware of in the code, and I cant test for things i'm not aware of so it makes no sense to me. Generally once I've built something that's it bombproof, nothing stops working because there is no reason for it to.