Panel:


Aimee Knight
AJ O’Neal
Charles Max Wood


Special Guest: Gil Tayar

In this episode, the panel talks with Gil Tayar who is currently residing in Tel Aviv and is a software engineer. He is currently the Senior Architect at Applitools in Israel. The panel and the guest talk about the different types of tests and when/how one is to use a certain test in a particular situation. They also mention Node, React, Selenium, Puppeteer, and much more!

Show Topics:

0:00 – Advertisement: KENDO UI

0:35 – Chuck: Our panel is AJ, Aimee, myself – and our special guest is Gil Tayar. Tell us why you are famous!

1:13 – Gil talks about where he resides and his background. 

2:27 – Chuck: What is the landscape like now with testing and testing tools now?

2:39 – Guest: There is a huge renaissance with the JavaScript community. Testing has moved forward in the frontend and backend. Today we have lots of testing tools.  We can do frontend testing that wasn’t possible 5 years ago. The major change was React.

The guest talks about Node, React, tools, and more!

4:17 – Aimee: I advocate for tests and testing. There is a grey area though...how do you treat that? If you have to get something into production, but it’s not THE thing to get into production, does that fall into product or...what?

5:02 – Guest: We decided to test everything in the beginning. We actually cam through and did that and since then I don’t think I can use the right code without testing. There are a lot of different situations, though, to consider.

The guest gives hypothetical situations that people could face.

6:27 – Aimee.

6:32 – Guest: The horror to changing code without tests, I don’t know, I haven’t done that for a while. You write with fear in your heart. Your design is driven by fear, and not what you think is right. In the beginning don’t write those tests, but...

7:22 – Aimee: I totally agree and I could go on and on and on.

7:42 – Panel: I want to do tests when I know they will create value. I don’t want to do it b/c it’s a mundane thing. Secondly, I find that some times I am in a situation where I cannot write the test b/c I would have to know the business logic is correct. I am in this discovery mode of what is the business logic? I am not just building your app.

I guess I just need advice in this area, I guess.

8:55 – Guest gives advice to panelist’s question. He mentions how there are two schools of thought.

10:20 – Guest: Don’t mock too much.

10:54 – Panel: Are unit tests the easiest? I just reach for unit testing b/c it helps me code faster. But 90% of my code is NOT that.

11:18 – Guest: Exactly! Most of our test is glue – gluing together a bunch of different stuff! Those are best tested as a medium-sized integration suite.

12:39 – Panel: That seems like a lot of work, though! I loathe the database stuff b/c they don’t map cleanly. I hate this database stuff.

13:06 – Guest: I agree, but don’t knock the database, but knock the level above the database.

13:49 – Guest: Yes, it takes time! Building the script and the testing tools, but when you have it then adding to it is zero time. Once you are in the air it’s smooth sailing.

14:17 – Panel: I guess I can see that. I like to do the dumb-way the first time. I am not clear on the transition.

14:47 – Guest: Write the code, and then write the tests.

The guest gives a hypothetical situation on how/when to test in a certain situation.

16:25 – Panel: Can you talk about that more, please?

16:50 – Guest: Don’t have the same unit – do browser and business logic stuff separated. The real business logic stuff needs to be above that level. First principle is separation of concerns.

18:04 – Panel talks about dependency interjection and asks a question.

18:27 – Guest: What I am talking about very, very light inter-dependency interjection.

19:19 – Panel: You have a main function and you are doing requires in the main function. You are passing the pieces of that into the components that need it.

19:44